search for: 766,11

...(struct iommu_domain *domain) domain->ops->flush_iotlb_all(domain); } -static inline void flush_iotlb_range(struct iommu_domain *domain, +static inline void iommu_flush_iotlb_range(struct iommu_domain *domain, unsigned long iova, size_t size, struct page *freelist) { @@ -764,6 +766,11 @@ static inline void iommu_set_fault_handler(struct iommu_domain *domain, { } +static inline int iommu_needs_bounce_buffer(struct device *dev) +{ + return 0; +} + static inline void iommu_get_resv_regions(struct device *dev, struct list_head *list) { -- 2.20.1

...ing you... */ IP_NF_ASSERT(master_ct(conntrack)); - conntrack->status =3D IPS_EXPECTED; + __set_bit(IPS_EXPECTED_BIT, &conntrack->status); conntrack->master =3D expected; expected->sibling =3D conntrack; LIST_DELETE(&ip_conntrack_expect_list, expected); @@ -768,11 +766,11 @@ *set_reply =3D 1; } else { /* Once we've had two way comms, always ESTABLISHED. */ - if (h->ctrack->status & IPS_SEEN_REPLY) { + if (test_bit(IPS_SEEN_REPLY_BIT, &h->ctrack->status)) { DEBUGP("ip_conntrack_in: normal packet for %p\n",...

...oid start_gather_func(int argc, char *a printf("Timeout set to %d seconds\n", timeout); } - if ( gettimeofday(&tv, NULL) == -1 ) + if ( gettimeofday(&tv, NULL) ) { fprintf(stderr, "failed to get timeofday\n"); return ; @@ -766,11 +788,8 @@ void cpufreq_para_func(int argc, char *a { int cpuid = -1; - if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 ) - cpuid = -1; - - if ( cpuid >= max_cpu_nr ) - cpuid = -1; + if ( argc > 0 ) + parse_cpuid(argv[0], &a...

...unsigned long addr) /* Jmp not a call (ignore the .e8) */ calc.e8 = 0xe9; - calc.offset = ftrace_calc_offset(ip + MCOUNT_INSN_SIZE, addr); + calc.offset = ftrace_calc_offset(ip + MCOUNT_RELINSN_SIZE, addr); /* * ftrace external locks synchronize the access to the static variable. @@ -766,11 +822,11 @@ create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size) * the jmp to ftrace_epilogue, as well as the address of * the ftrace_ops this trampoline is used for. */ - trampoline = alloc_tramp(size + MCOUNT_INSN_SIZE + sizeof(void *)); + trampoline = alloc_tramp(size +...

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. Changes since v7: - Rebased to

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. Changes since v7: - Rebased to

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. This patch-set is a rework of the

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. This patch-set is a rework of the

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the

This patchset converts the intel iommu driver to the dma-iommu api. While converting the driver I exposed a bug in the intel i915 driver which causes a huge amount of artifacts on the screen of my laptop. You can see a picture of it here: https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg This issue is most likely in the i915 driver and is most likely caused by the

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to