On Tue, 9 Jan 2018, Josh Poimboeuf wrote:
> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
> > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina wrote:
> > > On Fri, 5 Jan 2018, Dan Williams wrote:
> > >
> > > [ ... snip ... ]
> > >>
OP, and something comparable for eBPF JIT?
Is this going to be handled in eBPF in some other way?
Without that in place, and considering Jann Horn's paper, it would seem
like PTI doesn't really lock it down fully, right?
[1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=287305
--
Jiri Kosina
SUSE Labs
ut as printk() is currently writing out one of
> the other per-CPU buffers.
Please also take a look at per-CPU printk() function redirection mechanism
that got added because of printk()-from-NMI madness ('printk_func'
pointer). It might be useful for your purposes as well.
--
Jir
se exec("/sbin/reboot") ultimately succeeds.
But with all the timeouts, dbus, "Failed to issue method call: Did
not receive a reply" messages, this is getting close to impossible.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe
i_host_alloc(&driver_template,
> >> sizeof(TW_Device_Extension));
> >> if (!host) {
> >> TW_PRINTK(host, TW_DRIVER, 0x24, "Failed to allocate
> >> memory for device extension");
> >> @@ -2134,11 +2139,6 @@ st
_PARAM_PORTCOUNT,
TW_PARAM_PORTCOUNT_LENGTH)));
- /* Try to enable MSI */
- if (use_msi && (pdev->device != PCI_DEVICE_ID_3WARE_9000) &&
- !pci_enable_msi(pdev))
- set_bit(TW_USING_MSI, &tw_dev->flags);
-
/* Now setup t
completed), but it "just doesn't work".
> Any description of what this failure looks like to a user? How can a
> user or a distro connect a symptom (driver timeout, console message, or
> whatever) to this patch?
Will be hopefully part of the dmesg I will be providing later ...
basically any commands sent to it time out.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(it doesn't respond to any commands that are being sent to it after
> >> > initialization).
> >> >
> >> > Reverting d5dea7d95 or not force-disabling MSIs in pci_msi_init_pci_dev()
> >> > makes the device work properly again.
> >> >
> >> >
On Tue, 27 Aug 2013, Jiri Kosina wrote:
> On Tue, 27 Aug 2013, Jiri Kosina wrote:
>
> > Commit d5dea7d95 ("PCI: msi: Disable msi interrupts when we initialize a
> > pci device") makes MSIs be forcibly disabled at boot time.
> >
> > It turns out that thi
[ adding Bjorn and Eric to CC, sorry for omitting you originally ]
On Tue, 27 Aug 2013, Jiri Kosina wrote:
> Commit d5dea7d95 ("PCI: msi: Disable msi interrupts when we initialize a
> pci device") makes MSIs be forcibly disabled at boot time.
>
> It turns out that this b
ly
(it doesn't respond to any commands that are being sent to it after
initialization).
Reverting d5dea7d95 or not force-disabling MSIs in pci_msi_init_pci_dev()
makes the device work properly again.
Signed-off-by: Jiri Kosina
---
I am adding Adam Radford as a recepient as well, to see wh
; IS_ERR instead of a simple NULL pointer check.
>
> Signed-off-by: Joe Lawrence
> Cc: Jens Axboe
> Cc: Jiri Kosina
> Cc: "James E.J. Bottomley"
> Cc: Bart Van Assche
> Cc: linux-scsi@vger.kernel.org
> ---
> block/blk-core.c
Lawrence
> Cc: Jens Axboe
> Cc: Jiri Kosina
> Cc: "James E.J. Bottomley"
> Cc: Bart Van Assche
> Cc: linux-scsi@vger.kernel.org
> ---
> block/scsi_ioctl.c| 9 -
> drivers/block/paride/pd.c | 2 ++
> drivers/block/pktcdvd.c | 2 ++
Acked
lock(&(&ha->hardware_lock)->rlock);
lock(&(&ha->vport_slock)->rlock);
lock(&(&ha->hardware_lock)->rlock);
=== [ cut here ] ===
Fix the potential deadlock by disabling IRQs while holding ha->vport_slock.
Reported
0_configure_hba+0x197/0x3c0 [qla2xxx]
> [ 17.784924] but this lock was taken by another, HARDIRQ-safe lock in the
> past:
> [ 17.784924] (&(&ha->hardware_lock)->rlock){-.}
This seems to be real. You should be seeing that since 3.5-rc1 already
though ... ?
D
>> to mptsas_pci_table[].
> >>
> >> [1] http://comments.gmane.org/gmane.linux.scsi/63836
> >> [2] http://lkml.indiana.edu/hypermail/linux/kernel/0701.2/1715.html
> >>
> >> Signed-off-by: Jiri Kosina
> >> ---
> >>
> >>
> >> I gu
On Sat, 21 Jul 2012, Jiri Kosina wrote:
> The device identifies itself as
>
> 0d:05.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X
> Fusion-MPT SAS (rev 01) Subsystem: NEC Corporation SAS1068
>
> and seems to be functionally compatible with 0x0054 PID.
&g
several
times in the past (see [1] [2] and more), but aparently the PCI ID never made it
to mptsas_pci_table[].
[1] http://comments.gmane.org/gmane.linux.scsi/63836
[2] http://lkml.indiana.edu/hypermail/linux/kernel/0701.2/1715.html
Signed-off-by: Jiri Kosina
---
I guess the "Subsystem
18 matches
Mail list logo
