On Mon, 2021-03-01 at 18:41 +0530, Sumit Garg wrote:
> Current trusted keys framework is tightly coupled to use TPM device
> as an underlying implementation which makes it difficult for
> implementations like Trusted Execution Environment (TEE) etc. to
> provide trusted keys support in case
This libsas fix is for a problem that occurs when trying to change the
cache type of an ATA device and the libiscsi one is a regression fix
from this merge window.
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Jolly Shah (1):
scsi: libsas:
On Tue, 2021-04-13 at 00:45 -0500, Gustavo A. R. Silva wrote:
> Hi Martin,
>
> On 4/12/21 23:52, Martin K. Petersen wrote:
>
> > Silencing analyzer warnings shouldn't be done at the expense of
> > human
> > readers. If it is imperative to switch to flex_array_size() to
> > quiesce
> > checker
On Mon, 2021-04-12 at 17:01 +0100, Colin King wrote:
> From: Colin Ian King
>
> The kzalloc call can return null with the GFP_KERNEL flag so
> add a null check and exit via a new error exit label. Use the
> same exit error label for another error path too.
>
> Addresses-Coverity: ("Dereference
Seven fixes all in drivers. The hpsa three are the most extensive and
the most problematic: it's a packed structure misalignment that oopses
on ia64 but looks like it would also oops on quite a few non-x86
architectures. The pm80xx is a regression and the rest are bug fixes
for patches in the
On Thu, 2021-04-08 at 17:41 -0700, Steve Rutherford wrote:
> On Thu, Apr 8, 2021 at 2:15 PM James Bottomley
> wrote:
> > On Thu, 2021-04-08 at 12:48 -0700, Steve Rutherford wrote:
> > > On Thu, Apr 8, 2021 at 10:43 AM James Bottomley <
> > > j...@linux.ibm.com&g
On Thu, 2021-04-08 at 12:48 -0700, Steve Rutherford wrote:
> On Thu, Apr 8, 2021 at 10:43 AM James Bottomley
> wrote:
> > On Fri, 2021-04-02 at 16:20 +0200, Paolo Bonzini wrote:
> > > On 02/04/21 13:58, Ashish Kalra wrote:
> > > > Hi Nathan,
> > > >
On Fri, 2021-04-02 at 16:20 +0200, Paolo Bonzini wrote:
> On 02/04/21 13:58, Ashish Kalra wrote:
> > Hi Nathan,
> >
> > Will you be posting a corresponding Qemu patch for this ?
>
> Hi Ashish,
>
> as far as I know IBM is working on QEMU patches for guest-based
> migration helpers.
Yes, that's
Single fix to iscsi for a rare race condition which can cause a kernel
panic.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Gulam Mohamed (1):
scsi: iscsi: Fix race condition between login and sync thread
And
On Thu, 2021-04-01 at 18:50 +0530, Sumit Garg wrote:
> On Thu, 1 Apr 2021 at 15:36, Ahmad Fatoum
> wrote:
> > Hello Richard,
> >
> > On 31.03.21 21:36, Richard Weinberger wrote:
> > > James,
> > >
> > > - Ursprüngliche Mail
On Wed, 2021-03-31 at 20:36 +0200, Richard Weinberger wrote:
> James,
>
> - Ursprüngliche Mail -
> > Von: "James Bottomley"
> > > On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum <
> > > a.fat...@pengutronix.de wrote:
> > > >
On Wed, 2021-03-31 at 00:04 +0200, Richard Weinberger wrote:
> Ahmad,
>
> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum > wrote:
> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
>
> Is there a reason why we can't pass the desired backend name in the
> trusted key parameters?
>
Seven fixes, all in drivers (qla2xxx, mkt3sas, qedi, target, ibmvscsi).
The most serious are the target pscsi oom and the qla2xxx revert which
can otherwise cause a use after free.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short
On Wed, 2021-03-24 at 16:49 -0400, Mimi Zohar wrote:
> On Wed, 2021-03-24 at 09:14 -0700, James Bottomley wrote:
> > On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote:
> > > On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
> > > > Hello Horia,
> > &
On Tue, 2021-03-23 at 14:07 -0400, Mimi Zohar wrote:
> On Tue, 2021-03-23 at 17:35 +0100, Ahmad Fatoum wrote:
> > Hello Horia,
> >
> > On 21.03.21 21:48, Horia Geantă wrote:
> > > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
> > > [...]
> > > > +struct trusted_key_ops caam_trusted_key_ops = {
> > >
On Tue, 2021-03-23 at 12:20 -0400, Steven Rostedt wrote:
> On Mon, 22 Mar 2021 20:25:15 +0100
> Thorsten Leemhuis wrote:
>
> > I agree to the last point and yeah, maybe regressions are the more
> > important problem we should work on – at least from the perspective
> > of kernel development.
On Mon, 2021-03-22 at 13:16 -0400, Konstantin Ryabitsev wrote:
> On Mon, Mar 22, 2021 at 04:18:14PM +0100, Thorsten Leemhuis wrote:
> > Note, there is a second reason why ksummit-discuss is CCed: another
> > reason why I want to create this new list is making it easier to
> > find and track
Eight fixes, all in drivers, all fairly minor either being fixes in
error legs, memory leaks on teardown, context errors or semantic
problems.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Alexey Dobriyan (1):
10 updates, a non code maintainer update for vmw_pvscsi, five code
updates for ibmvfc and four for UFS. All updates are either trivial
patches or bug fixes.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Can Guo (2):
On Fri, 2021-03-12 at 18:26 +0200, Jarkko Sakkinen wrote:
> On Wed, Mar 10, 2021 at 02:26:27PM -0800, James Bottomley wrote:
> > On Wed, 2021-03-10 at 21:56 +0200, Jarkko Sakkinen wrote:
> > [...]
> > > I also need to apply
> > >
> > > https://lore.kerne
On Thu, 2021-03-11 at 01:49 +0100, Linus Walleij wrote:
> The use case for TPM on laptops is similar: it can be used by a
> provider to lock down a machine, but it can also be used by the
> random user to store keys. Very few users beside James
> Bottomley are capable of doing that (I
On Wed, 2021-03-10 at 21:56 +0200, Jarkko Sakkinen wrote:
[...]
> I also need to apply
>
> https://lore.kernel.org/linux-integrity/20210127190617.17564-1-james.bottom...@hansenpartnership.com/
>
> and I would like to do both while I'm at it.
>
> James, there was one patch that needed fixing
On Mon, 2021-03-08 at 13:32 -0600, Gustavo A. R. Silva wrote:
> Hi all,
>
> Friendly ping: who can review/take this, please?
Well, before embarking on a huge dynamic update, let's ask Broadcom the
simpler question of why isn't MPI2_IO_UNIT_PAGE_3_GPIO_VAL_MAX simply
set to 36? There's no
On Mon, 2021-03-08 at 11:34 +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./drivers/scsi/scsi_transport_iscsi.c:930:60-61: WARNING opportunity
> for kobj_to_dev().
I have to ask, what is the point of this? container_of is usually
pretty safe ... as in it will detect
On Fri, 2021-03-05 at 12:52 -0500, Paul Moore wrote:
[...]
> This draft seems fine to me, but there is a small logistical blocker
> at the moment which means I can't merge this until -rc2 is released,
> which likely means this coming Monday. The problem is that this
> patch relies on code that
On Fri, 2021-03-05 at 11:04 +1100, Stephen Rothwell wrote:
> Hi Martin,
>
> I notice that you have rebased the scsi-mkp tree. Unfotunately James
> has already merged part of the old version of the scsi-mkp tree int
> the scsi tree so that commits f69d02e37a85..39ae3edda325 in the scsi-
> mkp
This is a few driver updates (iscsi, mpt3sas) that were still in the
staging queue when the merge window opened (all committed on or before
8 Feb) and some small bug fixes which came in during the merge window
(all committed on 22 Feb).
The patch is available here:
> Add a capability for userspace to mirror SEV encryption context from
> one vm to another. On our side, this is intended to support a
> Migration Helper vCPU, but it can also be used generically to support
> other in-guest workloads scheduled by the host. The intention is for
> the primary guest
On Sat, 2021-02-20 at 01:32 +, Matthew Garrett wrote:
> Under certain circumstances it might be desirable to enable the
> creation of TPM-backed secrets that are only accessible to the
> kernel. In an ideal world this could be achieved by using TPM
> localities, but these don't appear to be
On Mon, 2021-02-22 at 11:17 -0800, Dan Williams wrote:
> On Mon, Feb 22, 2021 at 2:24 AM Mike Rapoport
> wrote:
> > On Mon, Feb 22, 2021 at 07:34:52AM +, Matthew Garrett wrote:
> > > On Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote:
> > >
> > > > It is unsafe to allow saving of
This series consists of the usual driver updates (ufs, ibmvfc, qla2xxx,
hisi_sas, pm80xx) plus the removal of the gdth driver (which is bound
to cause conflicts with a trivial change somewhere). The only big
major rework of note is the one from Hannes trying to clean up our
result handling code
On Tue, 2021-02-16 at 18:16 +0100, David Hildenbrand wrote:
[...]
> > > The discussion regarding migratability only really popped up
> > > because this is a user-visible thing and not being able to
> > > migrate can be a real problem (fragmentation, ZONE_MOVABLE, ...).
> >
> > I think the
On Tue, 2021-02-16 at 17:34 +0100, David Hildenbrand wrote:
> On 16.02.21 17:25, James Bottomley wrote:
> > On Mon, 2021-02-15 at 20:20 +0100, Michal Hocko wrote:
> > [...]
> > > > >What kind of flags are we talking about and why would that
> > > >
On Mon, 2021-02-15 at 20:20 +0100, Michal Hocko wrote:
[...]
> > > What kind of flags are we talking about and why would that be a
> > > problem with memfd_create interface? Could you be more specific
> > > please?
> >
> > You mean what were the ioctl flags in the patch series linked
> > above?
On Mon, 2021-02-15 at 10:13 +0100, Michal Hocko wrote:
> On Sun 14-02-21 11:21:02, James Bottomley wrote:
> > On Sun, 2021-02-14 at 10:58 +0100, David Hildenbrand wrote:
> > [...]
> > > > And here we come to the question "what are the differences that
&
On Sun, 2021-02-14 at 10:58 +0100, David Hildenbrand wrote:
[...]
> > And here we come to the question "what are the differences that
> > justify a new system call?" and the answer to this is very
> > subjective. And as such we can continue bikeshedding forever.
>
> I think this fits into the
One fix for scsi_debug that fixes a memory leak on module removal.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Maurizio Lombardi (1):
scsi: scsi_debug: Fix a memory leak
And the diffstat:
On Wed, 2021-02-10 at 08:01 +, David Woodhouse wrote:
>
> On 10 February 2021 07:45:54 GMT, Yang Song <
> songy...@linux.alibaba.com> wrote:
> > Use a customized signature service supported by openssl engine
> > to sign the kernel module.
> > Add command line parameters that support engine
One fix in drivers (lpfc) that stops an oops on resource exhaustion.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
James Smart (1):
scsi: lpfc: Fix EEH encountering oops with NVMe traffic
And the diffstat:
On Fri, 2021-02-05 at 13:25 -0400, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 08:48:11AM -0800, James Bottomley wrote:
[...]
> > The practical consequence of this model is that if you allocate a
> > chip structure with tpm_chip_alloc() you have to release it again
> > by
On Fri, 2021-02-05 at 04:18 +0200, Jarkko Sakkinen wrote:
> On Thu, Feb 04, 2021 at 04:34:11PM -0800, James Bottomley wrote:
> > On Fri, 2021-02-05 at 00:50 +0100, Lino Sanfilippo wrote:
> > > From: Lino Sanfilippo
> > >
> > > In tpm2_del_space() chip-&g
On Fri, 2021-02-05 at 13:25 -0400, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 08:48:11AM -0800, James Bottomley wrote:
> > > Thanks for pointing this out. I'd strongly support Jason's
> > > proposal:
> > >
> > > https://lore.kernel.org/linux-i
On Thu, 2021-02-04 at 20:44 -0500, Stefan Berger wrote:
> To clarify: When I tested this I had *both* patches applied. Without
> the patches I got the null pointer exception in tpm2_del_space(). The
> 2nd patch alone solves that issue when using the steps above.
Yes, I can't confirm the bug
On Fri, 2021-02-05 at 00:50 +0100, Lino Sanfilippo wrote:
> From: Lino Sanfilippo
>
> In tpm2_del_space() chip->ops is used for flushing the sessions.
> However
> this function may be called after tpm_chip_unregister() which sets
> the chip->ops pointer to NULL.
> Avoid a possible NULL pointer
On Wed, 2021-02-03 at 16:43 +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warning:
>
> ./drivers/scsi/isci/init.c:140:8-16: WARNING: use scnprintf or
> sprintf.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/scsi/isci/init.c | 2 +-
> 1 file changed,
On Tue, 2021-02-02 at 20:15 +0200, Mike Rapoport wrote:
> On Tue, Feb 02, 2021 at 03:34:29PM +0100, David Hildenbrand wrote:
> > On 02.02.21 15:32, Michal Hocko wrote:
> > > On Tue 02-02-21 15:26:20, David Hildenbrand wrote:
> > > > On 02.02.21 15:22, Michal Hocko wrote:
> > > > > On Tue 02-02-21
On Fri, 2021-01-29 at 09:23 +0100, Michal Hocko wrote:
> On Thu 28-01-21 13:05:02, James Bottomley wrote:
> > Obviously the API choice could be revisited
> > but do you have anything to add over the previous discussion, or is
> > this just to get your access control?
>
> existing dm-crypt volume, this key is fixed. A key can be loaded into
> user key type and used by dm-crypt (cryptsetup can already do it this
> way). But at this point, you can still do 'keyctl read' on that key,
> exposing the key material to user space.
>
> Currently, wit
On Sat, 2021-01-30 at 19:36 -0800, Guenter Roeck wrote:
> On 1/30/21 4:41 PM, James Bottomley wrote:
> > On Sat, 2021-01-30 at 15:49 -0800, Guenter Roeck wrote:
> > > On 1/29/21 2:59 PM, Jarkko Sakkinen wrote:
> > > > On Tue, Jan 26, 2021 at 04:46:07PM +0100, Łuka
On Sat, 2021-01-30 at 15:49 -0800, Guenter Roeck wrote:
> On 1/29/21 2:59 PM, Jarkko Sakkinen wrote:
> > On Tue, Jan 26, 2021 at 04:46:07PM +0100, Łukasz Majczak wrote:
> > > Hi Jarkko, Guenter
> > >
> > > Yes, here are the logs when failure occurs -
> > >
Two minor fixes in drivers. Both changing strings (one in a comment,
one in a module help text) with no code impact.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Enzo Matsumiya (1):
scsi: qla2xxx: Fix
On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:
> On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:
> > Hello,
> >
> > I've been looking into how a migration to using trusted/encrypted
> > keys would look like (particularly with dm-crypt).
> >
> > Currently, it seems the the only
On Sat, 2021-01-30 at 19:15 +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 28, 2021 at 07:38:21PM -0800, Linus Torvalds wrote:
> > On Thu, Jan 28, 2021 at 4:54 PM Jarkko Sakkinen
> > wrote:
> > > This contains bug fixes for tpm_tis driver, which had a racy wait
> > > for hardware state change to be
On Thu, 2021-01-28 at 14:01 +0100, Michal Hocko wrote:
> On Thu 28-01-21 11:22:59, Mike Rapoport wrote:
[...]
> > I like the idea to have a pool as an optimization rather than a
> > hard requirement but I don't see why would it need a careful access
> > control. As the direct map fragmentation is
On Thu, 2021-01-28 at 14:01 +0100, Michal Hocko wrote:
> On Thu 28-01-21 11:22:59, Mike Rapoport wrote:
[...]
> > One of the major pushbacks on the first RFC [1] of the concept was
> > about the direct map fragmentation. I tried really hard to find
> > data that shows what is the performance
On Tue, 2021-01-26 at 16:46 +0100, Łukasz Majczak wrote:
> Hi Jarkko, Guenter
>
> Yes, here are the logs when failure occurs -
> https://gist.github.com/semihalf-majczak-lukasz/1575461f585f1e7fb1e9366b8eceaab9
> Look for a phrase "TPM returned invalid status"
We've had other reports of this:
Twelve minor fixes, all in drivers or doc. Most of the fixes are
pretty obvious (although we have 2 goes to get the UFS sysfs doc right)
and the biggest change is in the ufs driver which they've extensively
tested.
The patch is available here:
On Wed, 2021-01-20 at 15:22 +0800, Jiapeng Zhong wrote:
> Fix the following coccicheck warning:
>
> ./drivers/scsi/qla4xxx/ql4_attr.c: WARNING: use scnprintf or
> sprintf
>
> The snprintf() function returns the number of characters which would
> have been printed if there were enough space, but
Nine minor fixes, 7 in drivers and 2 in the core SCSI disk driver (sd)
which should be harmless involving removing an unused variable and
quietening a spurious warning.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
y output.
>
> The length of the last sysfs_emit_at call is 1 and it should instead
> be
> ignored. Do so.
>
> Fixes: e28bf1f03b01 ("RDMA: Convert various random sprintf sysfs
> _show uses to sysfs_emit")
>
> Reported-by: James Bottomley
> Signed-off-by: Joe P
On Tue, 2020-09-15 at 20:49 -0400, Eric Snowberg wrote:
> The Secure Boot Forbidden Signature Database, dbx, contains a list of
> now revoked signatures and keys previously approved to boot with UEFI
> Secure Boot enabled. The dbx is capable of containing any number of
>
On Wed, 2021-01-13 at 13:40 +, David Howells wrote:
> Hi Linus,
>
> Are you willing to take this between merge windows - or does it need
> to wait for the next merge window? It's not technically a bug fix to
> the kernel, but it does have a CVE attached to it.
>
> Note that I've also
This is two driver fixes (megaraid_sas and hisi_sas). The megaraid one
is a revert of a previous revert of a cpu hotplug fix which exposed a
bug in the block layer which has been fixed in this merge window and
the hisi_sas performance enhancement comes from switching to interrupt
managed
On Thu, 2021-01-07 at 19:43 +0800, lijinlin wrote:
[...]
> - SCSI_LOG_ERROR_RECOVERY(3,
> + if (bdr_scmd->request && bdr_scmd->request->rq_disk)
> sdev_printk(KERN_INFO, sdev,
> - "%s: Sending BDR\n", current-
>
On Sun, 2021-01-03 at 19:49 +0100, Arnd Bergmann wrote:
> On Sun, Jan 3, 2021 at 6:00 PM James Bottomley
> wrote:
> > On Sun, 2021-01-03 at 17:26 +0100, Arnd Bergmann wrote:
> > [...]
> > > @@ -8209,7 +8208,7 @@ megasas_mgmt_fw_ioctl(struct
> > &
On Sun, 2021-01-03 at 17:26 +0100, Arnd Bergmann wrote:
[...]
> @@ -8209,7 +8208,7 @@ megasas_mgmt_fw_ioctl(struct megasas_instance
> *instance,
> if (instance->consistent_mask_64bit)
> put_unaligned_le64(sense_handle, sense_ptr);
> else
> -
On Sun, 2021-01-03 at 15:01 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> A previous patch tried to avoid a build failure, but missed one case
> that Kconfig warns about:
>
> WARNING: unmet direct dependencies detected for CHELSIO_T4
> Depends on [m]: NETDEVICES [=y] && ETHERNET [=y]
On Fri, 2021-01-01 at 13:21 -0800, Linus Torvalds wrote:
> On Fri, Jan 1, 2021 at 12:19 PM James Bottomley
> wrote:
> > Originally this change was slated for the merge window but a late
> > arriving build problem with CONFIG_PM=n derailed that.
>
> So I've pulled this,
This is a load of driver fixes (12 ufs, 1 mpt3sas, 1 cxgbi). The big
core two fixes are for power management ("block: Do not accept any
requests while suspended" and "block: Fix a race in the runtime power
management code") which finally sorts out the resume problems we've
occasionally been
On Tue, 2020-12-29 at 21:51 +0800, Zheng Yongjun wrote:
> Use kzalloc rather than kcalloc(1,...)
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
What's the reason for wanting to do this transformation?
> drivers/char/tpm/tpm1-cmd.c | 2 +-
> 1 file
On Wed, 2020-12-23 at 15:23 -0500, Douglas Gilbert wrote:
> On 2020-12-23 11:04 a.m., James Bottomley wrote:
> > On Wed, 2020-12-23 at 15:51 +, Christoph Hellwig wrote:
> > > On Wed, Dec 23, 2020 at 12:52:59PM +, Pavel Begunkov wrote:
> > > > Can scatter
On Wed, 2020-12-23 at 15:51 +, Christoph Hellwig wrote:
> On Wed, Dec 23, 2020 at 12:52:59PM +, Pavel Begunkov wrote:
> > Can scatterlist have 0-len entries? Those are directly translated
> > into bvecs, e.g. in nvme/target/io-cmd-file.c and
> > target/target_core_file.c. I've audited most
On Tue, 2020-12-15 at 10:51 -0800, James Bottomley wrote:
> On Tue, 2020-12-15 at 16:38 +0300, Sergey Temerkhanov wrote:
> > Avoid race condition at shutdown by shutting downn the TPM 2.0
> > devices synchronously. This eliminates the condition when the
> > shutdown sequence s
This series consists of the usual driver updates (ufs, qla2xxx,
smartpqi, target, zfcp, fnic, mpt3sas, ibmvfc) plus a load of cleanups,
a major power management rework and a load of assorted minor updates.
There are a few core updates (formatting fixes being the big one) but
nothing major this
On Tue, 2020-12-15 at 16:38 +0300, Sergey Temerkhanov wrote:
> Avoid race condition at shutdown by shutting downn the TPM 2.0
> devices synchronously. This eliminates the condition when the
> shutdown sequence sets chip->ops to NULL leading to the following:
>
> [ 1586.593561][ T8669]
xed, but with that
Tested-by: James Bottomley
Attached is the test programme I used.
James
---
#!/usr/bin/python3
##
# Python script get an attestation and verify it with the PEK
#
# This assumes you've already exported the pek.cert with sev-tool
# from https://github.com/AMDESE/sev-tool.git
#
# sev-t
Five small fixes: four in drivers: hisi_sas: fix internal queue
timeout, be2iscsi: revert a prior fix causing problems, bnx2i: add
missing dependency, storvsc: late arriving revert of a problem fix, and
one in the core. The core one is a minor change to stop paying
attention to the busy count
On Fri, 2020-12-11 at 06:01 -0500, Mimi Zohar wrote:
> On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:
> > On 2020-11-29 08:17:38, Mimi Zohar wrote:
> > > Hi Sasha,
> > >
> > > On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote:
> > > > On Wed, Jul 08, 2020 at 12:13:13PM -0400, Mimi Zohar
On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote:
> On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > Just as a side note. I was looking at tpm_tis_probe_irq_single()
> > and that function is leaking the interrupt request if any of the
> > checks afterwards fails, except
On Mon, 2020-12-07 at 19:35 +0100, Greg KH wrote:
> On Mon, Dec 07, 2020 at 06:26:03PM +, Christoph Hellwig wrote:
> > On Mon, Dec 07, 2020 at 07:23:12PM +0100, Greg KH wrote:
> > > What "real workload" test can be run on this to help show if it
> > > is useful or not? These vendors seem to
On Sun, 2020-12-06 at 17:40 +0100, Thomas Gleixner wrote:
> On Sat, Dec 05 2020 at 12:39, Jarkko Sakkinen wrote:
> > On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote:
> > > To try and detect potential interrupt storms that
> > > have been occurring with tpm_tis devices it was
On Sat, 2020-12-05 at 22:20 +0100, Ard Biesheuvel wrote:
> On Sat, 5 Dec 2020 at 22:15, James Bottomley
> wrote:
> > [Rostedt added because this is all his fault]
> > On Sat, 2020-12-05 at 21:57 +0100, Ard Biesheuvel wrote:
> > > On Sat, 5 Dec 2020 at 21:24, J
[Rostedt added because this is all his fault]
On Sat, 2020-12-05 at 21:57 +0100, Ard Biesheuvel wrote:
> On Sat, 5 Dec 2020 at 21:24, James Bottomley
> wrote:
[...]
> > > So I don't object to using str_has_prefix() in new code in this
> > > way, but I really don't s
On Sat, 2020-12-05 at 20:36 +0100, Ard Biesheuvel wrote:
> On Fri, 4 Dec 2020 at 19:02, James Bottomley
> wrote:
> > On Fri, 2020-12-04 at 18:07 +0100, Ard Biesheuvel wrote:
> > > On Fri, 4 Dec 2020 at 18:06,
> > > wrote:
> > > > From: Francis Laniel
&g
Four small fixes in two drivers. The mpt3sas fixes are all timeout
under unusual conditions problems and the storvsc is a missed incoming
packet validation and a missed error return.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short
On Fri, 2020-12-04 at 14:51 -0700, Jerry Snitselaar wrote:
> James Bottomley @ 2020-12-03 14:05 MST:
>
> > On Thu, 2020-12-03 at 13:14 -0700, Jerry Snitselaar wrote:
> > > Jerry Snitselaar @ 2020-12-02 23:11 MST:
> > [...]
> > > > The interrupt storm
On Fri, 2020-12-04 at 18:07 +0100, Ard Biesheuvel wrote:
> On Fri, 4 Dec 2020 at 18:06,
> wrote:
> > From: Francis Laniel
> >
> > The two functions indicates if a string begins with a given prefix.
> > The only difference is that strstarts() returns a bool while
> > str_has_prefix()
> > returns
On Fri, 2020-12-04 at 18:03 +0100, laniel_fran...@privacyrequired.com
wrote:
> In this patch set, I replaced all calls to strstarts() by calls to
> str_has_prefix(). Indeed, the kernel has two functions to test if a
> string begins with an other:
> 1. strstarts() which returns a bool, so 1 if the
On Thu, 2020-12-03 at 14:17 -0500, Konstantin Ryabitsev wrote:
> On Thu, Dec 03, 2020 at 08:55:54AM -0800, Joe Perches wrote:
> > Perhaps automate a mechanism to capture that information as
> > git notes for the patches when applied.
>
> Git notes have a limited usefulness for this -- they are
On Thu, 2020-12-03 at 13:14 -0700, Jerry Snitselaar wrote:
> Jerry Snitselaar @ 2020-12-02 23:11 MST:
[...]
> > The interrupt storm detection code works on the T490s. I'm not sure
> > what is going on with the L490. I will see if I can get access to
> > one.
> >
> > Jerry
>
> Lenovo verified
On Thu, 2020-12-03 at 13:52 -0500, Matthew Wilcox wrote:
> It's not so much "clean history" that's the desire. It's "don't leave
> landmines for git bisect".
... top posting?
Well functional git bisect and show the evolution of the patch aren't
mutually exclusive. Plus our current clean history
On Thu, 2020-12-03 at 00:43 +0100, Vlastimil Babka wrote:
> Hi,
>
> there was a bit of debate on Twitter about this, so I thought I would
> bring it here. Imagine a scenario where patch sits as a commit in
> -next and there's a bug report or fix, possibly by a bot or with some
> static analysis.
On Mon, 2020-11-30 at 10:26 +0800, Ding Hui wrote:
[...]
> sg_ses -e
> Diagnostic pages, followed by abbreviation(s) then page code:
> Supported Diagnostic Pages [sdp] [0x0]
> Configuration (SES) [cf] [0x1]
> Enclosure Status/Control (SES) [ec,es] [0x2]
> Help Text (SES)
On Sun, 2020-11-29 at 09:52 -0800, Randy Dunlap wrote:
> On 11/29/20 9:47 AM, Tom Rix wrote:
> > On 11/27/20 11:53 AM, Matthew Wilcox wrote:
> > > On Fri, Nov 27, 2020 at 11:07:07AM -0800, t...@redhat.com wrote:
> > > > +++ b/fs/fcntl.c
> > > > @@ -526,7 +526,7 @@ SYSCALL_DEFINE3(fcntl64, unsigned
in this situation is
refuse to attach like the proposed patch below.
It does seem a bit odd that someone would build an enclosure that
doesn't enclose anything, so would you mind running
sg_ses -e
on it and reporting back what it shows? It's possible there's another
type that the enclosure device s
Three small fixes in the UFS driver: two are for power management
issues and the third is to fix a slew of problem in the sysfs code.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Can Guo (2):
scsi: ufs: Make
On Fri, 2020-11-27 at 10:29 -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
> ---
> drivers/scsi/sym53c8xx_2/sym_glue.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because i
On Tue, 2020-11-24 at 10:52 -0700, Jerry Snitselaar wrote:
> Before diving further into that though, does anyone else have an
> opinion on ripping out the irq code, and just using polling? We've
> been only polling since 2015 anyways.
Well only a biased one, obviously: polling causes large
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> wrote:
> > Well, I used git. It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 20
1 - 100 of 4683 matches
Mail list logo
