On 18-02-21 07:52 AM, Mark Lord wrote:
> On 18-02-21 03:35 AM, Naveen N. Rao wrote:
..
>> Looks good to me, but I am not able to apply this patch. There seems to be
>> whitespace damage.
>
> Here (attached) is a clean copy.
Again, this time with the commit message included
On 18-02-21 03:35 AM, Naveen N. Rao wrote:
> Mark Lord wrote:
>> I am using SECCOMP to filter syscalls on a ppc32 platform,
>> and noticed that the JIT compiler was failing on the BPF
>> even though the interpreter was working fine.
>>
>> The issue was that th
instruction.
Signed-Off-By: Mark Lord
--- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.0 -0500
+++ linux/arch/powerpc/net/bpf_jit_comp.c 2018-02-20 14:41:20.805227494
-0500
@@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
BUILD_BUG_ON
On 13-10-11 04:41 AM, Alexander Gordeev wrote:
> On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote:
>> Just to help us all understand "the loop" issue..
>>
>> Here's an example of driver code which uses the existing MSI-X interfaces,
>> for a dev
Just to help us all understand "the loop" issue..
Here's an example of driver code which uses the existing MSI-X interfaces,
for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt.
This is from a new driver I'm working on right now:
static int xx_alloc_msix_irqs (struct xx_dev
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in mysterio
On 13-09-26 09:03 AM, Alexander Gordeev wrote:
> On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
>> On 13-09-18 05:48 AM, Alexander Gordeev wrote:
>>> The last pattern makes most of sense to me and could be updated with a more
>>> clear sequenc
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
>
> The last pattern makes most of sense to me and could be updated with a more
> clear sequence - a call to (bit modified) pci_msix_table_size() followed
> by a call to pci_enable_msix(). I think this pattern can effectively
> supersede the currently
Sergei Shtylyov wrote:
Bartlomiej Zolnierkiewicz wrote:
hdparm explicitely marks HDIO_[UNREGISTER,SCAN]_HWIF ioctls as DANGEROUS
and given the number of bugs we can assume that there are no real users:
..
There is the odd user of these, actually.
But the most recent to email me (a few weeks
