Re: [PATCH 4.4 00/78] 4.4.108-stable review
On Sat, Dec 23, 2017 at 05:30:42PM -0800, Guenter Roeck wrote: > On 12/22/2017 12:45 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.108 release. > > There are 78 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun Dec 24 08:45:30 UTC 2017. > > Anything received after that time might be too late. > > > > For v4.4.107-79-g0989207: > > Build results: > total: 145 pass: 144 fail: 1 > Failed builds: > alpha:allmodconfig > Qemu test results: > total: 118 pass: 118 fail: 0 > > The alpha fix is missing from > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > branch linux-4.4.y; it points to the same sha. Ah, I only updated my quilt tree, sorry about that, let me go push this out now... greg k-h
Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG
On 12/24/2017 12:45 PM, Tetsuo Handa wrote:
Matthew Wilcox wrote:
+ unsigned long pfn = page_to_pfn(page);
+ int ret;
+
+ *pfn_min = min(pfn, *pfn_min);
+ *pfn_max = max(pfn, *pfn_max);
+
+ do {
+ if (xb_preload(GFP_NOWAIT | __GFP_NOWARN) < 0)
+ return -ENOMEM;
+
+ ret = xb_set_bit(&vb->page_xb, pfn);
+ xb_preload_end();
+ } while (unlikely(ret == -EAGAIN));
OK, so you don't need a spinlock because you're under a mutex? But you
can't allocate memory because you're in the balloon driver, and so a
GFP_KERNEL allocation might recurse into your driver?
Right. We can't (directly or indirectly) depend on __GFP_DIRECT_RECLAIM &&
!__GFP_NORETRY
allocations because the balloon driver needs to handle OOM notifier callback.
Would GFP_NOIO
do the job? I'm a little hazy on exactly how the balloon driver works.
GFP_NOIO implies __GFP_DIRECT_RECLAIM. In the worst case, it can lockup due to
the too small to fail memory allocation rule. GFP_NOIO | __GFP_NORETRY would
work
if there is really a guarantee that GFP_NOIO | __GFP_NORETRY never depend on
__GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocations, which is too subtle for me
to
validate. The direct reclaim dependency is too complicated to validate.
I consider that !__GFP_DIRECT_RECLAIM is the future-safe choice.
What's the problem with (or how is it better than) the "GFP_NOWAIT |
__GFP_NOWARN" we are using here?
If you can't preload with anything better than that, I think that
xb_set_bit() should attempt an allocation with GFP_NOWAIT | __GFP_NOWARN,
and then you can skip the preload; it has no value for you.
Yes, that's why I suggest directly using kzalloc() at xb_set_bit().
It has some possibilities to remove that preload if we also do the
bitmap allocation in the xb_set_bit():
bitmap = rcu_dereference_raw(*slot);
if (!bitmap) {
bitmap = this_cpu_xchg(ida_bitmap, NULL);
if (!bitmap) {
bitmap = kmalloc(sizeof(*bitmap), gfp);
if (!bitmap)
return -ENOMEM;
}
}
But why not just follow the radix tree implementation style that puts
the allocation in preload, which would be invoked with a more relaxed
gfp in other use cases?
Its usage in virtio_balloon is just a little special that we need to put
the allocation within the balloon_lock, which doesn't give us the
benefit of using a relaxed gfp in preload, but it doesn't prevent us
from living with the current APIs (i.e. the preload + xb_set pattern).
On the other side, if we do it as above, we have more things that need
to consider. For example, what if the a use case just want the radix
tree implementation style, which means it doesn't want allocation within
xb_set(), then would we be troubled with how to avoid the allocation
path in that case?
So, I think it is better to stick with the convention by putting the
allocation in preload. Breaking the convention should show obvious
advantages, IMHO.
@@ -173,8 +292,15 @@ static unsigned fill_balloon(struct virtio_balloon *vb,
size_t num)
while ((page = balloon_page_pop(&pages))) {
balloon_page_enqueue(&vb->vb_dev_info, page);
+ if (use_sg) {
+ if (xb_set_page(vb, page, &pfn_min, &pfn_max) < 0) {
+ __free_page(page);
+ continue;
+ }
+ } else {
+ set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
+ }
Is this the right behaviour?
I don't think so. In the worst case, we can set no bit using xb_set_page().
If we can't record the page in the xb,
wouldn't we rather send it across as a single page?
I think that we need to be able to fallback to !use_sg path when OOM.
I also have different thoughts:
1) For OOM, we have leak_balloon_sg_oom (oom has nothing to do with
fill_balloon), which does not use xbitmap to record pages, thus no
memory allocation.
2) If the memory is already under pressure, it is pointless to continue
inflating memory to the host. We need to give thanks to the memory
allocation failure reported by xbitmap, which gets us a chance to
release the inflated pages that have been demonstrated to cause the
memory pressure of the guest.
Best,
Wei
Re: [PATCH v20 3/7 RESEND] xbitmap: add more operations
On 12/23/2017 10:33 PM, Tetsuo Handa wrote:
+ bitmap = rcu_dereference_raw(*slot);
+ if (!bitmap) {
+ bitmap = this_cpu_xchg(ida_bitmap, NULL);
+ if (!bitmap)
+ return -ENOMEM;
I can't understand this. I can understand if it were
BUG_ON(!bitmap);
because you called xb_preload().
But
/*
* Regular test 2
* set bit 2000, 2001, 2040
* Next 1 in [0, 2048) --> 2000
* Next 1 in [2000, 2002) --> 2000
* Next 1 in [2002, 2041) --> 2040
* Next 1 in [2002, 2040) --> none
* Next 0 in [2000, 2048) --> 2002
* Next 0 in [2048, 2060) --> 2048
*/
xb_preload(GFP_KERNEL);
assert(!xb_set_bit(&xb1, 2000));
assert(!xb_set_bit(&xb1, 2001));
assert(!xb_set_bit(&xb1, 2040));
[...]
xb_preload_end();
you are not calling xb_preload() prior to each xb_set_bit() call.
This means that, if each xb_set_bit() is not surrounded with
xb_preload()/xb_preload_end(), there is possibility of hitting
this_cpu_xchg(ida_bitmap, NULL) == NULL.
This is just a lazy test. We "know" that the bits in the range 1024-2047
will all land in the same bitmap, so there's no need to preload for each
of them.
Testcases also serves as how to use that API.
Assuming such thing leads to incorrect usage.
If callers are aware that the bits that they going to record locate in
the same bitmap, I think they should also perform the xb_ APIs with only
one preload. So the test cases here have shown them a correct example.
We can probably add some comments above to explain this.
Best,
Wei
Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot
Thank you for the swift reply! On Sat, Dec 23, 2017 at 07:30:21PM -0800, Linus Torvalds wrote: > On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu > wrote: > > > > For testing purposes, I've altered machine_kexec_32.c making the > > following toy commit. It naively undoes part of e802a51, solely to > > confirm that's where it goes awry in my setup. > > That's really funky. > > The idt_invalidate() seems to do *exactly* the same thing. It uses > "load_idt()" on an IDT with size 0, and the supplied address. > > Can you disassemble your "set_idt()" code vs the "idt_invalidate()"? > I seem to have done some such thing just now, but please excuse some poking around in the dark here (I've disassembled code exactly once before: yesterday, in answering a similar request for more info in another lkml thread..). I'm actually not even certain the sequel is what you are asking. I couldn't find the set_idt symbol in arch/x86/kernel/machine_kexec_32.o. Google seemed to think this has something to do with the 'static' marker for that function, so I made another commit differing from the previous one only in that it removes that marker (i.e. set_idt is now 'void' rather than 'static void'). I can now see that function with objdump. The relevant sections of objdump -D on the two files are: --- arch/x86/kernel/machine_kexec_32.o --- 0180 : 180: e8 fc ff ff ff call 181 185: 55 push %ebp 186: 89 e5 mov%esp,%ebp 188: 83 ec 0csub$0xc,%esp 18b: 89 45 f8mov%eax,-0x8(%ebp) 18e: 66 89 55 f6 mov%dx,-0xa(%ebp) 192: 8d 45 f6lea-0xa(%ebp),%eax 195: 65 8b 0d 14 00 00 00mov%gs:0x14,%ecx 19c: 89 4d fcmov%ecx,-0x4(%ebp) 19f: 31 c9 xor%ecx,%ecx 1a1: ff 15 20 00 00 00 call *0x20 1a7: 8b 45 fcmov-0x4(%ebp),%eax 1aa: 65 33 05 14 00 00 00xor%gs:0x14,%eax 1b1: 75 02 jne1b5 1b3: c9 leave 1b4: c3 ret 1b5: e8 fc ff ff ff call 1b6 1ba: 8d b6 00 00 00 00 lea0x0(%esi),%esi -- and --- arch/x86/kernel/idt.o --- : 0: e8 fc ff ff ff call 1 5: 55 push %ebp 6: 89 e5 mov%esp,%ebp 8: 83 ec 0csub$0xc,%esp b: 65 8b 15 14 00 00 00mov%gs:0x14,%edx 12: 89 55 fcmov%edx,-0x4(%ebp) 15: 31 d2 xor%edx,%edx 17: 31 d2 xor%edx,%edx 19: 89 45 f8mov%eax,-0x8(%ebp) 1c: 8d 45 f6lea-0xa(%ebp),%eax 1f: 66 89 55 f6 mov%dx,-0xa(%ebp) 23: ff 15 20 00 00 00 call *0x20 29: 8b 45 fcmov-0x4(%ebp),%eax 2c: 65 33 05 14 00 00 00xor%gs:0x14,%eax 33: 75 02 jne37 35: c9 leave 36: c3 ret 37: e8 fc ff ff ff call 38 --- I've also checked again that this newer compilation still gives a well-behaved kexec. > > Is this expected behaviour? > > No. The code literally seems identical. The only difference is > > (a) where the 0 limit comes from > > (b) perhaps build flags and whether it is inlined or not due to being > in a different file > > and neither of those should matter, but maybe they do. > > Which is why I'd like you to actually look at the generated code and > see if you can see any difference.. > > Linus
Re: [PATCH 11/11] evm: Don't update hmacs in user ns mounts
On Sun, 2017-12-24 at 00:12 -0500, Mimi Zohar wrote: > Hi Serge, > > On Fri, 2017-12-22 at 22:03 -0600, Serge E. Hallyn wrote: > > On Fri, Dec 22, 2017 at 03:32:35PM +0100, Dongsu Park wrote: > > > From: Seth Forshee > > > > > > The kernel should not calculate new hmacs for mounts done by > > > non-root users. Update evm_calc_hmac_or_hash() to refuse to > > > calculate new hmacs for mounts for non-init user namespaces. > > > > > > Cc: linux-integr...@vger.kernel.org > > > Cc: linux-security-mod...@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org > > > Cc: James Morris > > > Cc: Mimi Zohar > > > > Hi Mimi, > > > > does this change seem sufficient to you? > > I think this is the correct behavior in the context of fuse file > systems. This patch, the "ima: define a new policy option named > force" patch, and an updated IMA policy should be upstreamed together. > The cover letter should provide the motivation for these patches. Ah, this patch is being upstreamed with the fuse mounts patches. I guess Seth is planning on posting the IMA policy changes for fuse separately. Mimi
[PATCH 11/12] staging: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/staging/vboxvideo/vbox_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/vboxvideo/vbox_ttm.c
b/drivers/staging/vboxvideo/vbox_ttm.c
index 4eb410a..4da1723 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -241,7 +241,6 @@ static struct ttm_bo_driver vbox_bo_driver = {
.verify_access = vbox_bo_verify_access,
.io_mem_reserve = &vbox_ttm_io_mem_reserve,
.io_mem_free = &vbox_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int vbox_mm_init(struct vbox_private *vbox)
--
2.7.4
[PATCH 03/12] drm/bochs: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/bochs/bochs_mm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index c4cadb6..857755a 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -205,7 +205,6 @@ struct ttm_bo_driver bochs_bo_driver = {
.verify_access = bochs_bo_verify_access,
.io_mem_reserve = &bochs_ttm_io_mem_reserve,
.io_mem_free = &bochs_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int bochs_mm_init(struct bochs_device *bochs)
--
2.7.4
[PATCH 01/12] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL
From: Michal Srb
The io_mem_pfn field was added in commit
ea642c3216cb2a60d1c0e760ae47ee85c9c16447
and is called unconditionally. However, not all drivers were updated to set it.
Use the ttm_bo_default_io_mem_pfn function if a driver did not set its own.
Signed-off-by: Michal Srb
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index c8ebb75..e25a99b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
if (bo->mem.bus.is_iomem) {
/* Iomem should not be marked encrypted */
cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
- pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+ if (bdev->driver->io_mem_pfn)
+ pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+ else
+ pfn = ttm_bo_default_io_mem_pfn(bo,
page_offset);
} else {
page = ttm->pages[page_offset];
if (unlikely(!page && i == 0)) {
--
2.7.4
[PATCH 10/12] drm/vmwgfx: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index c705632..828dd59 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -859,5 +859,4 @@ struct ttm_bo_driver vmw_bo_driver = {
.fault_reserve_notify = &vmw_ttm_fault_reserve_notify,
.io_mem_reserve = &vmw_ttm_io_mem_reserve,
.io_mem_free = &vmw_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
--
2.7.4
[PATCH 12/12] drm/ttm: unexport ttm_bo_default_io_mem_pfn and make it static
No one will use this function except in ttm_bo_vm.c now. So unexport it
and make it static.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 23 +++
include/drm/ttm/ttm_bo_api.h| 11 ---
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index e25a99b..ff70fc96 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -92,6 +92,21 @@ static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
return ret;
}
+/**
+ * ttm_bo_default_iomem_pfn - get a pfn for a page offset
+ *
+ * @bo: the BO we need to look up the pfn for
+ * @page_offset: offset inside the BO to look up.
+ *
+ * Calculate the PFN for iomem based mappings during page fault
+ */
+static unsigned long ttm_bo_default_io_mem_pfn(struct ttm_buffer_object *bo,
+ unsigned long page_offset)
+{
+ return ((bo->mem.bus.base + bo->mem.bus.offset) >> PAGE_SHIFT)
+ + page_offset;
+}
+
static int ttm_bo_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
@@ -407,14 +422,6 @@ static struct ttm_buffer_object *ttm_bo_vm_lookup(struct
ttm_bo_device *bdev,
return bo;
}
-unsigned long ttm_bo_default_io_mem_pfn(struct ttm_buffer_object *bo,
- unsigned long page_offset)
-{
- return ((bo->mem.bus.base + bo->mem.bus.offset) >> PAGE_SHIFT)
- + page_offset;
-}
-EXPORT_SYMBOL(ttm_bo_default_io_mem_pfn);
-
int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
struct ttm_bo_device *bdev)
{
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index fa07be1..0b1ce05 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -711,17 +711,6 @@ extern int ttm_fbdev_mmap(struct vm_area_struct *vma,
struct ttm_buffer_object *bo);
/**
- * ttm_bo_default_iomem_pfn - get a pfn for a page offset
- *
- * @bo: the BO we need to look up the pfn for
- * @page_offset: offset inside the BO to look up.
- *
- * Calculate the PFN for iomem based mappings during page fault
- */
-unsigned long ttm_bo_default_io_mem_pfn(struct ttm_buffer_object *bo,
- unsigned long page_offset);
-
-/**
* ttm_bo_mmap - mmap out of the ttm device address space.
*
* @filp: filp as input from the mmap method.
--
2.7.4
[PATCH 08/12] drm/radeon: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/radeon/radeon_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 6ada64d..8595c76 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -844,7 +844,6 @@ static struct ttm_bo_driver radeon_bo_driver = {
.fault_reserve_notify = &radeon_bo_fault_reserve_notify,
.io_mem_reserve = &radeon_ttm_io_mem_reserve,
.io_mem_free = &radeon_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int radeon_ttm_init(struct radeon_device *rdev)
--
2.7.4
[PATCH 06/12] drm/nouveau: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 435ff86..8de82a3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1667,5 +1667,4 @@ struct ttm_bo_driver nouveau_bo_driver = {
.fault_reserve_notify = &nouveau_ttm_fault_reserve_notify,
.io_mem_reserve = &nouveau_ttm_io_mem_reserve,
.io_mem_free = &nouveau_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
--
2.7.4
[PATCH 07/12] drm/qxl: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/qxl/qxl_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index ab48238..a86eaf9 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -393,7 +393,6 @@ static struct ttm_bo_driver qxl_bo_driver = {
.verify_access = &qxl_verify_access,
.io_mem_reserve = &qxl_ttm_io_mem_reserve,
.io_mem_free = &qxl_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
.move_notify = &qxl_bo_move_notify,
};
--
2.7.4
[PATCH 00/12] drm: add check if io_mem_pfn is NULL and cleanup
I found an OOPS when I used the mainline kernel for graphical tests in Hisilicon D05, I do not know how to solve this problem until I saw your discussion on this issue a month ago: https://lists.freedesktop.org/archives/dri-devel/2017-November/159046.html And my problem can be solved perfectly by your solution. This is important for me, I want to solve this problem as soon as possible. So I follow the result of your discussion, make and send these patches below. If anything is not good, please point it out, thanks. Michal Srb (1): drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL Tan Xiaojun (11): drm/ast: remove the default io_mem_pfn set drm/bochs: remove the default io_mem_pfn set drm/cirrus: remove the default io_mem_pfn set drm/mgag200: remove the default io_mem_pfn set drm/nouveau: remove the default io_mem_pfn set drm/qxl: remove the default io_mem_pfn set drm/radeon: remove the default io_mem_pfn set drm/virtio: remove the default io_mem_pfn set drm/vmwgfx: remove the default io_mem_pfn set staging: remove the default io_mem_pfn set drm/ttm: unexport ttm_bo_default_io_mem_pfn and make it static drivers/gpu/drm/ast/ast_ttm.c | 1 - drivers/gpu/drm/bochs/bochs_mm.c | 1 - drivers/gpu/drm/cirrus/cirrus_ttm.c| 1 - drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 - drivers/gpu/drm/nouveau/nouveau_bo.c | 1 - drivers/gpu/drm/qxl/qxl_ttm.c | 1 - drivers/gpu/drm/radeon/radeon_ttm.c| 1 - drivers/gpu/drm/ttm/ttm_bo_vm.c| 28 +++- drivers/gpu/drm/virtio/virtgpu_ttm.c | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 1 - drivers/staging/vboxvideo/vbox_ttm.c | 1 - include/drm/ttm/ttm_bo_api.h | 11 --- 12 files changed, 19 insertions(+), 30 deletions(-) -- 2.7.4
[PATCH 05/12] drm/mgag200: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 3e7e1cd..89b550f 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -237,7 +237,6 @@ struct ttm_bo_driver mgag200_bo_driver = {
.verify_access = mgag200_bo_verify_access,
.io_mem_reserve = &mgag200_ttm_io_mem_reserve,
.io_mem_free = &mgag200_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int mgag200_mm_init(struct mga_device *mdev)
--
2.7.4
[PATCH 09/12] drm/virtio: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/virtio/virtgpu_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c
b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index cd389c5..4a12434 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -431,7 +431,6 @@ static struct ttm_bo_driver virtio_gpu_bo_driver = {
.verify_access = &virtio_gpu_verify_access,
.io_mem_reserve = &virtio_gpu_ttm_io_mem_reserve,
.io_mem_free = &virtio_gpu_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
.move_notify = &virtio_gpu_bo_move_notify,
.swap_notify = &virtio_gpu_bo_swap_notify,
};
--
2.7.4
[PATCH 04/12] drm/cirrus: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/cirrus/cirrus_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 1ff1838..2c652af 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -237,7 +237,6 @@ struct ttm_bo_driver cirrus_bo_driver = {
.verify_access = cirrus_bo_verify_access,
.io_mem_reserve = &cirrus_ttm_io_mem_reserve,
.io_mem_free = &cirrus_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int cirrus_mm_init(struct cirrus_device *cirrus)
--
2.7.4
[PATCH 02/12] drm/ast: remove the default io_mem_pfn set
The default interface situation has been taken into the framework, so
remove the default set of each module.
Signed-off-by: Tan Xiaojun
---
drivers/gpu/drm/ast/ast_ttm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 696a15d..fdd521d 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -237,7 +237,6 @@ struct ttm_bo_driver ast_bo_driver = {
.verify_access = ast_bo_verify_access,
.io_mem_reserve = &ast_ttm_io_mem_reserve,
.io_mem_free = &ast_ttm_io_mem_free,
- .io_mem_pfn = ttm_bo_default_io_mem_pfn,
};
int ast_mm_init(struct ast_private *ast)
--
2.7.4
[PATCH v3] ARM: sun8i: h2+: add support for Banana Pi M2 Zero board
Banana Pi M2 Zero board is a H2+-based board by Sinovoip, with a form
factor and GPIO holes similar to Raspberry Pi Zero.
It features:
- Allwinner H2+ SoC
- Single-chip (16-bit) 512MiB DDR3 DRAM
- Ampak AP6212 Wi-Fi/Bluetooth module
- MicroSD slot
- Two MicroUSB Type-B ports (one can only be used to power the board and
the other features OTG functionality)
- Two keys, a reset and a GPIO-connected key.
- HDMI Type-C (miniHDMI) connector connected to the HDMI part of H2+.
- CSI connector to connect the camera sensor provided by Sinovoip.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Add comments about Vbus problem in &usbphy node.
Changes in v2:
- Use high active SD card detect on the production batch.
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts| 162 +
2 files changed, 163 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0bb8db33704a..937a8768671f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -962,6 +962,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-a83t-tbs-a711.dtb \
sun8i-h2-plus-orangepi-r1.dtb \
+ sun8i-h2-plus-bananapi-m2-zero.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-beelink-x2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
new file mode 100644
index ..5bc182ddc5f7
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
@@ -0,0 +1,162 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng
+ *
+ * Based on sun8i-h3-bananapi-m2-plus.dts, which is:
+ * Copyright (C) 2016 Chen-Yu Tsai
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+
+/ {
+ model = "Banana Pi BPI-M2-Zero";
+ compatible = "sinovoip,bpi-m2-zero", "allwinner,sun8i-h2-plus";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+
+ pwr_led {
+ label = "bananapi-m2-zero:red:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
+ default-state = "on";
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+
+ sw4 {
+ label = "power";
+ linux,code = ;
+ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+
Re: [PATCH 11/11] evm: Don't update hmacs in user ns mounts
Hi Serge, On Fri, 2017-12-22 at 22:03 -0600, Serge E. Hallyn wrote: > On Fri, Dec 22, 2017 at 03:32:35PM +0100, Dongsu Park wrote: > > From: Seth Forshee > > > > The kernel should not calculate new hmacs for mounts done by > > non-root users. Update evm_calc_hmac_or_hash() to refuse to > > calculate new hmacs for mounts for non-init user namespaces. > > > > Cc: linux-integr...@vger.kernel.org > > Cc: linux-security-mod...@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Cc: James Morris > > Cc: Mimi Zohar > > Hi Mimi, > > does this change seem sufficient to you? I think this is the correct behavior in the context of fuse file systems. This patch, the "ima: define a new policy option named force" patch, and an updated IMA policy should be upstreamed together. The cover letter should provide the motivation for these patches. Mimi > > > Cc: "Serge E. Hallyn" > > Signed-off-by: Seth Forshee > > Signed-off-by: Dongsu Park > > --- > > security/integrity/evm/evm_crypto.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/security/integrity/evm/evm_crypto.c > > b/security/integrity/evm/evm_crypto.c > > index bcd64baf..729f4545 100644 > > --- a/security/integrity/evm/evm_crypto.c > > +++ b/security/integrity/evm/evm_crypto.c > > @@ -190,7 +190,8 @@ static int evm_calc_hmac_or_hash(struct dentry *dentry, > > int error; > > int size; > > > > - if (!(inode->i_opflags & IOP_XATTR)) > > + if (!(inode->i_opflags & IOP_XATTR) || > > + inode->i_sb->s_user_ns != &init_user_ns) > > return -EOPNOTSUPP; > > > > desc = init_desc(type); > > -- > > 2.13.6 >
Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller
On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote: > On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov > wrote: > > There is a clock controller functionality provided by the APCS hardware > > block of msm8916 devices. The device-tree would represent an APCS node > > with both mailbox and clock provider properties. > > > The spec might depict a 'clock' box and 'mailbox' box inside the > bigger APCS box. However, from the code I see in this patchset, they > are orthogonal and can & should be represented as independent DT > nodes. The APCS consists of a number of different hardware blocks, one of them being the "APCS global" block, which is what this node and drivers relate to. On 8916 this contains both the IPC register and clock control. But it's still just one block according to the hardware specification. As such DT should describe the one hardware block by one node IMHO. The fact that we in Linux split this into two different drivers is an unrelated implementation detail. Regards, Bjorn
Linux 4.15-rc5
Ok, so it's not Sunday yet, but tomorrow is Christmas Eve, and while I've been in the US for over two decades, we still celebrate Christmas the only _right_ way - with Christmas Eve being the big day, and Christmas Day being just for recovery. So I'm doing the rc5 release a day early, in order to not have to do it during the actual Christmas festivities at our house. And it's not like I expect to see a lot of patches or pull requests tomorrow anyway, so I guess it doesn't really much matter when I do the rc release, the end result would look very similar even if I had done it on my normal Sunday schedule. This (shortened) week ended up being fairly normal for rc5, with the exception of the ongoing merging of the x86 low-level prep for kernel page table isolation that continues and is noticeable. In fact, about a third of the rc5 patch is x86 updates due to that. It all looks like very good cleanups, though, and it's been through about two hundred iterations by now (no, seriously, Thomas has been keeping track of his iterative updates of the PTI series, and it apparently hit 196 in the last two months). Outside of that, things look fairly normal: mostly drivers and some networking updates (bpf fixes and selftests are notable). Some xfs fixes also stand out. The appended shortlog gives an overview of the details, Linus --- Adiel Aloni (1): mac80211_hwsim: enable TODS BIT in null data frame Albert Hsieh (1): mtd: nand: brcmnand: Zero bitflip is not an error Alexander Kochetkov (2): net: arc_emac: fix arc_emac_rx() error paths net: arc_emac: restart stalled EMAC Alexei Starovoitov (2): bpf: fix integer overflows bpf: do not allow root to mangle valid pointers Alexey Khoroshilov (1): net: phy: xgene: disable clk on error paths Alexey Kodanev (1): vxlan: restore dev->mtu setting based on lower device Andy Lutomirski (24): x86/unwinder/orc: Dont bail on stack overflow x86/irq: Remove an old outdated comment about context tracking races x86/irq/64: Print the offending IP in the stack overflow warning x86/entry/64: Allocate and enable the SYSENTER stack x86/dumpstack: Add get_stack_info() support for the SYSENTER stack x86/entry/gdt: Put per-CPU GDT remaps in ascending order x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce struct cpu_entry_area x86/kasan/64: Teach KASAN about the cpu_entry_area x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss x86/dumpstack: Handle stack overflow on all stacks x86/entry: Move SYSENTER_stack to the beginning of struct tss_struct x86/entry: Remap the TSS into the CPU entry area x86/entry/64: Separate cpu_current_top_of_stack from TSS.sp0 x86/espfix/64: Stop assuming that pt_regs is on the entry stack x86/entry/64: Use a per-CPU trampoline stack for IDT entries x86/entry/64: Return to userspace from the trampoline stack x86/entry/64: Create a per-CPU SYSCALL entry trampoline x86/entry/64: Move the IST stacks into struct cpu_entry_area x86/entry/64: Remove the SYSENTER stack canary x86/entry: Clean up the SYSENTER_stack code x86/entry/64: Make cpu_entry_area.tss read-only x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy x86/vsyscall/64: Warn and fail vsyscall emulation in NATIVE mode x86/mm/64: Improve the memory map documentation Anju T Sudhakar (2): powerpc/perf/imc: Fix nest-imc cpuhotplug callback failure powerpc/perf: Fix kfree memory allocated for nest pmus Bart Van Assche (1): scsi: core: Use blist_flags_t consistently Ben Skeggs (6): drm/nouveau/bios/dp: support DP Info Table 2.0 drm/nouveau/imem/nv50: fix refcount_t warning drm/nouveau/mmu/gp10b: use correct implementation drm/nouveau: avoid GPU page sizes > PAGE_SIZE for buffer objects in host memory drm/nouveau: use alternate memory type for system-memory buffers with kind != 0 drm/nouveau: fix obvious memory leak Bhawanpreet Lakha (1): drm/amd/display: add pipe locking before front end programing Boris Ostrovsky (2): x86/entry/64/paravirt: Use paravirt-safe macro to access eflags xen/balloon: Mark unallocated host memory as UNUSABLE Brendan McGrath (1): ipv6: icmp6: Allow icmp messages to be looped back Brian King (1): tg3: Fix rx hang on MTU change with 5717/5719 Cai Li (1): clk: fix a panic error caused by accessing NULL pointer Chen-Yu Tsai (1): clk: sunxi: sun9i-mmc: Implement reset callback for reset controls Chris Wilson (6): drm/i915: Flush pending GTT writes before unbinding drm/i915: Drop fb reference on load_detect_pipe failure path drm/i915: Stop listening to request resubmission from the signaler kthread drm/i915/fence: Use rcu to defer freeing of irq_work drm/i915/lpe: Remove double-encapsulation of i
Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG
Matthew Wilcox wrote:
> > + unsigned long pfn = page_to_pfn(page);
> > + int ret;
> > +
> > + *pfn_min = min(pfn, *pfn_min);
> > + *pfn_max = max(pfn, *pfn_max);
> > +
> > + do {
> > + if (xb_preload(GFP_NOWAIT | __GFP_NOWARN) < 0)
> > + return -ENOMEM;
> > +
> > + ret = xb_set_bit(&vb->page_xb, pfn);
> > + xb_preload_end();
> > + } while (unlikely(ret == -EAGAIN));
>
> OK, so you don't need a spinlock because you're under a mutex? But you
> can't allocate memory because you're in the balloon driver, and so a
> GFP_KERNEL allocation might recurse into your driver?
Right. We can't (directly or indirectly) depend on __GFP_DIRECT_RECLAIM &&
!__GFP_NORETRY
allocations because the balloon driver needs to handle OOM notifier callback.
>Would GFP_NOIO
> do the job? I'm a little hazy on exactly how the balloon driver works.
GFP_NOIO implies __GFP_DIRECT_RECLAIM. In the worst case, it can lockup due to
the too small to fail memory allocation rule. GFP_NOIO | __GFP_NORETRY would
work
if there is really a guarantee that GFP_NOIO | __GFP_NORETRY never depend on
__GFP_DIRECT_RECLAIM && !__GFP_NORETRY allocations, which is too subtle for me
to
validate. The direct reclaim dependency is too complicated to validate.
I consider that !__GFP_DIRECT_RECLAIM is the future-safe choice.
>
> If you can't preload with anything better than that, I think that
> xb_set_bit() should attempt an allocation with GFP_NOWAIT | __GFP_NOWARN,
> and then you can skip the preload; it has no value for you.
Yes, that's why I suggest directly using kzalloc() at xb_set_bit().
>
> > @@ -173,8 +292,15 @@ static unsigned fill_balloon(struct virtio_balloon
> > *vb, size_t num)
> >
> > while ((page = balloon_page_pop(&pages))) {
> > balloon_page_enqueue(&vb->vb_dev_info, page);
> > + if (use_sg) {
> > + if (xb_set_page(vb, page, &pfn_min, &pfn_max) < 0) {
> > + __free_page(page);
> > + continue;
> > + }
> > + } else {
> > + set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
> > + }
>
> Is this the right behaviour?
I don't think so. In the worst case, we can set no bit using xb_set_page().
> If we can't record the page in the xb,
> wouldn't we rather send it across as a single page?
>
I think that we need to be able to fallback to !use_sg path when OOM.
[PATCH 1/3] mtd: spi-nor: add optional DMA-safe bounce buffer for data transfer
This patch has two purposes:
1 - To fix the compatible issue between the MTD and SPI sub-systems
The MTD sub-system has no particular requirement about the memory areas it
uses. Especially, ubifs is well known for using vmalloc'ed buffers, which
then are not DMA-safe. There are reasons behind that, so we have to deal
with it.
On the other hand, the SPI sub-system clearly states in the kernel doc for
'struct spi-transfer' (include/linux/spi/spi.h) that both .tx_buf and
.rx_buf must point into "dma-safe memory". This requirement has not been
taken into account by the m25p80.c driver, at the border between MTD and
SPI, for a long time now. So it's high time to fix this issue.
2 - To help other SPI flash controller drivers to perform DMA transfers
Those controller drivers suffer the same issue as those behind the
m25p80.c driver in the SPI sub-system: They may be provided by the MTD
sub-system with buffers not suited to DMA operations. We want to avoid
each controller to implement its own bounce buffer so we offer them some
optional bounce buffer, allocated and managed by the spi-nor framework
itself, as an helper to add support to DMA transfers.
Then the patch adds two hardware capabilities for SPI flash controllers,
SNOR_HWCAPS_WR_BOUNCE and SNOR_HWCAPS_RD_BOUNCE.
SPI flash controller drivers are supposed to use them to request the
spi-nor framework to allocate an optional bounce buffer in some
DMA-safe memory area then to use it in some cases during (Fast) Read
and/or Page Program operations.
More precisely, the bounce buffer is used if and only if two conditions
are met:
1 - The SPI flash controller driver has declared the
SNOR_HWCAPS_RD_BOUNCE, resp. SNOR_HWCAPS_WR_BOUNCE for (Fast) Read,
resp. Page Program operations.
2 - The buffer provided by the above MTD layer is not already in a
DMA-safe area.
This policy avoid using the bounce buffer when not explicitly requested
or when not needed, hence limiting the performance penalty.
Besides, the bounce buffer is allocated once for all at the very first
time it is actually needed. This means that as long as all buffers
provided by the above MTD layer are allocated in some DMA-safe areas, the
bounce buffer itself is never allocated.
Finally, the bounce buffer size is limited to 256KiB, the currently known
maximum erase sector size. This tradeoff should still provide good
performances even if new memory parts come with even larger erase sector
sizes, limiting the memory footprint at the same time.
Signed-off-by: Cyrille Pitchen
---
drivers/mtd/devices/m25p80.c | 4 +-
drivers/mtd/spi-nor/spi-nor.c | 136 +++---
include/linux/mtd/spi-nor.h | 8 +++
3 files changed, 139 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index a4e18f6aaa33..60878c62a654 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -239,7 +239,9 @@ static int m25p_probe(struct spi_device *spi)
struct spi_nor_hwcaps hwcaps = {
.mask = SNOR_HWCAPS_READ |
SNOR_HWCAPS_READ_FAST |
- SNOR_HWCAPS_PP,
+ SNOR_HWCAPS_PP |
+ SNOR_HWCAPS_RD_BOUNCE |
+ SNOR_HWCAPS_WR_BOUNCE,
};
char *flash_name;
int ret;
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 8bafd462f0ae..59f9fbd45234 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -14,8 +14,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -1232,6 +1234,56 @@ static const struct flash_info spi_nor_ids[] = {
{ },
};
+static bool spi_nor_is_dma_safe(const void *buf)
+{
+ if (is_vmalloc_addr(buf))
+ return false;
+
+#ifdef CONFIG_HIGHMEM
+ if ((unsigned long)buf >= PKMAP_BASE &&
+ (unsigned long)buf < (PKMAP_BASE + (LAST_PKMAP * PAGE_SIZE)))
+ return false;
+#endif
+
+ return true;
+}
+
+static int spi_nor_get_bounce_buffer(struct spi_nor *nor,
+u_char **buffer,
+size_t *buffer_size)
+{
+ const struct flash_info *info = nor->info;
+ /*
+* Limit the size of the bounce buffer to 256KB: this is currently
+* the largest known erase sector size (> page size) and should be
+* enough to still reach good performances if some day new memory
+* parts use even larger erase sector sizes.
+*/
+ size_t size = min_t(size_t, info->sector_size, SZ_256K);
+
+ /*
+* Allocate the bounce buffer once for all at the first time it is
+* actually needed. This prevents wasting some precious memory
+* in cases where it would never be needed.
+*/
+ if (unlikely(!nor->bounce_buffer)) {
+ nor->bounce_buffer = devm_
[PATCH 2/3] dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap,memcpy'
The optional 'dmacap,memcpy' DT property tells the Atmel QSPI controller
driver to reserve some DMA channel then to use it to perform DMA
memcpy() during data transfers. This feature relies on the generic
bounce buffer helper from spi-nor.c.
Signed-off-by: Cyrille Pitchen
---
Documentation/devicetree/bindings/mtd/atmel-quadspi.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
index b93c1e2f25dd..002d3f0a445b 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
@@ -12,6 +12,10 @@ Required properties:
- #address-cells: Should be <1>.
- #size-cells:Should be <0>.
+Optional properties:
+- dmacap,memcpy: Reserve a DMA channel to perform DMA memcpy() between the
+ system memory and the QSPI mapped memory.
+
Example:
spi@f002 {
@@ -24,6 +28,7 @@ spi@f002 {
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_spi0_default>;
+ dmacap,memcpy;
m25p80@0 {
...
--
2.11.0
[PATCH 3/3] mtd: atmel-quadspi: add support of DMA memcpy()
This patch takes advantage of the new bounce buffer helper from the
spi-nor framework to add support of memcpy() operations using the DMA
controller.
Since the number of DMA channels is limited and to avoid changing how
those DMA channels are used in existing boards, this new DMA memcpy()
feature is enabled only if the "dmacap,memcpy" boolean property is set in
the device-tree.
Signed-off-by: Cyrille Pitchen
---
drivers/mtd/spi-nor/atmel-quadspi.c | 132 +++-
1 file changed, 129 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c
b/drivers/mtd/spi-nor/atmel-quadspi.c
index 6c5708bacad8..5443e4dba416 100644
--- a/drivers/mtd/spi-nor/atmel-quadspi.c
+++ b/drivers/mtd/spi-nor/atmel-quadspi.c
@@ -22,6 +22,8 @@
#include
#include
+#include
+#include
#include
#include
#include
@@ -36,6 +38,8 @@
#include
#include
+#define QSPI_DMA_THRESHOLD 32
+
/* QSPI register offsets */
#define QSPI_CR 0x /* Control Register */
#define QSPI_MR 0x0004 /* Mode Register */
@@ -161,6 +165,11 @@ struct atmel_qspi {
struct spi_nor nor;
u32 clk_rate;
struct completion cmd_completion;
+
+ /* DMA transfers */
+ struct dma_chan *chan;
+ dma_addr_t dma_mem;
+ struct completion transfer_complete;
};
struct atmel_qspi_command {
@@ -197,11 +206,96 @@ static inline void qspi_writel(struct atmel_qspi *aq, u32
reg, u32 value)
writel_relaxed(value, aq->regs + reg);
}
+static void atmel_qspi_dma_callback(void *param)
+{
+ struct atmel_qspi *aq = param;
+
+ complete(&aq->transfer_complete);
+}
+
+static int atmel_qspi_run_dma_transfer(struct atmel_qspi *aq,
+ const struct atmel_qspi_command *cmd)
+{
+ struct device *dev = &aq->pdev->dev;
+ enum dma_data_direction dir;
+ struct dma_async_tx_descriptor *desc;
+ dma_addr_t src, dst, dma_addr;
+ dma_cookie_t cookie;
+ u32 offset;
+ void *ptr;
+ int err = 0;
+
+ if (cmd->tx_buf) {
+ ptr = (void *)cmd->tx_buf;
+ dir = DMA_TO_DEVICE;
+ } else if (cmd->rx_buf) {
+ ptr = cmd->rx_buf;
+ dir = DMA_FROM_DEVICE;
+ } else {
+ return -EINVAL;
+ }
+
+ dma_addr = dma_map_single(dev, ptr, cmd->buf_len, dir);
+ if (dma_mapping_error(dev, dma_addr))
+ return -ENOMEM;
+
+ offset = cmd->enable.bits.address ? cmd->address : 0;
+ if (cmd->tx_buf) {
+ dst = aq->dma_mem + offset;
+ src = dma_addr;
+ } else {
+ dst = dma_addr;
+ src = aq->dma_mem + offset;
+ }
+
+ desc = dmaengine_prep_dma_memcpy(aq->chan, dst, src, cmd->buf_len,
+DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ if (!desc) {
+ err = -ENOMEM;
+ goto unmap;
+ }
+
+ reinit_completion(&aq->transfer_complete);
+ desc->callback = atmel_qspi_dma_callback;
+ desc->callback_param = aq;
+
+ cookie = dmaengine_submit(desc);
+ err = dma_submit_error(cookie);
+ if (err) {
+ err = -EIO;
+ goto unmap;
+ }
+
+ dma_async_issue_pending(aq->chan);
+ err = wait_for_completion_timeout(&aq->transfer_complete,
+ msecs_to_jiffies(cmd->buf_len));
+ if (err <= 0) {
+ dmaengine_terminate_sync(aq->chan);
+ err = -ETIMEDOUT;
+ goto unmap;
+ }
+
+ err = 0;
+
+ unmap:
+ dma_unmap_single(dev, dma_addr, cmd->buf_len, dir);
+ return err;
+}
+
static int atmel_qspi_run_transfer(struct atmel_qspi *aq,
const struct atmel_qspi_command *cmd)
{
void __iomem *ahb_mem;
+ /* Try DMA transfer first. */
+ if (aq->chan && cmd->buf_len >= QSPI_DMA_THRESHOLD) {
+ int err = atmel_qspi_run_dma_transfer(aq, cmd);
+
+ /* If the DMA transfer has started, stop here. */
+ if (err != -ENOMEM)
+ return err;
+ }
+
/* Then fallback to a PIO transfer (memcpy() DOES NOT work!) */
ahb_mem = aq->mem;
if (cmd->enable.bits.address)
@@ -604,7 +698,7 @@ static irqreturn_t atmel_qspi_interrupt(int irq, void
*dev_id)
static int atmel_qspi_probe(struct platform_device *pdev)
{
- const struct spi_nor_hwcaps hwcaps = {
+ struct spi_nor_hwcaps hwcaps = {
.mask = SNOR_HWCAPS_READ |
SNOR_HWCAPS_READ_FAST |
SNOR_HWCAPS_READ_1_1_2 |
@@ -657,19 +751,44 @@ static int atmel_qspi_probe(struct platform_device *pdev)
goto exit;
}
+ aq->dma_mem = (dma_addr_t)res->start;
+
+ /* Reserve a D
[PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI
Hi all, this series tries to solve a long time issue of compatibility between the MTD and SPI sub-systems about whether we should use DMA-safe memory. This issue is visible espcecially when using a UBI file-system on a SPI NOR memory accessed through a SPI controller behind the m25p80 driver. The SPI sub-system has already implemented a work-around on its side, based on the spi_map_buf() function. However this function has its own limitation too. Especially, even if it builds a 'struct scatterlist' from a vmalloc'ed buffer, calling dma_map_sg() is still not safe on all architectures. Especially, on ARM cores using either VIPT or VIVT data caches, dma_map_sg() doesn't take the cache aliases issue into account. Then numerous crashes were reported for such architectures. If think it's high time to provide a reliable solution. So let's try to work together! The proposed solution here is based on an former series from Vignesh R and relies on a bounce buffer. For this series, I will need some pieces of advice on how to implement a reliable [spi_nor_]is_dma_safe() function. The proposed implementation in patch 1 is based on the tests performed by spi_map_buf() but I was wondring whether it would be more cautious to consider: DMA-safe <=> allocated by kmalloc'ed. Actually, it's better using the bounce buffer when not needed than not using it when we should. Also the bounce buffer solution in spi-nor is designed so it could be used as an helper so spi flash controller drivers other than m25p80.c could now easily add support to DMA transfers for (Fast) Read and/or Page Program operations. I've implemented and tested it on a sama5d2 xplained board + Macronix mx25l25673g SPI NOR memory reading from and writing into some UBI file-system. I've also tested with mtd_debug to write then read back a raw data into the SPI NOR memory, later checking the data integrity with sha1sum. For the atmel-quadspi.c driver, DMA memcpy() transfers are enabled only if the "dmacap,mempcy" boolean property is set in the device-tree. I found this name in some other device-trees already using it for a boolean property. Best regards, Cyrille Cyrille Pitchen (3): mtd: spi-nor: add optional DMA-safe bounce buffer for data transfer dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap,memcpy' mtd: atmel-quadspi: add support of DMA memcpy() .../devicetree/bindings/mtd/atmel-quadspi.txt | 5 + drivers/mtd/devices/m25p80.c | 4 +- drivers/mtd/spi-nor/atmel-quadspi.c| 132 +++- drivers/mtd/spi-nor/spi-nor.c | 136 +++-- include/linux/mtd/spi-nor.h| 8 ++ 5 files changed, 273 insertions(+), 12 deletions(-) -- 2.11.0
[PATCH] b43: Replace mdelay with msleep in b43_radio_2057_init_post
b43_radio_2057_init_post is not called in an interrupt handler nor holding a spinlock. The function mdelay in it can be replaced with msleep, to reduce busy wait. Signed-off-by: Jia-Ju Bai --- drivers/net/wireless/broadcom/b43/phy_n.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c b/drivers/net/wireless/broadcom/b43/phy_n.c index a5557d7..5bc838e 100644 --- a/drivers/net/wireless/broadcom/b43/phy_n.c +++ b/drivers/net/wireless/broadcom/b43/phy_n.c @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct b43_wldev *dev) b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78); b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80); - mdelay(2); + msleep(2); b43_radio_mask(dev, R2057_RFPLL_MISC_CAL_RESETN, ~0x78); b43_radio_mask(dev, R2057_XTAL_CONFIG2, ~0x80); -- 1.7.9.5
[PATCH] sky2: Replace mdelay with msleep in sky2_vpd_wait
sky2_vpd_wait is not called in an interrupt handler nor holding a spinlock. The function mdelay in it can be replaced with msleep, to reduce busy wait. Signed-off-by: Jia-Ju Bai --- drivers/net/ethernet/marvell/sky2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c index 9efe177..9fe8530 100644 --- a/drivers/net/ethernet/marvell/sky2.c +++ b/drivers/net/ethernet/marvell/sky2.c @@ -4287,7 +4287,7 @@ static int sky2_vpd_wait(const struct sky2_hw *hw, int cap, u16 busy) dev_err(&hw->pdev->dev, "VPD cycle timed out\n"); return -ETIMEDOUT; } - mdelay(1); + msleep(1); } return 0; -- 1.7.9.5
Re: [linus:master] BUILD REGRESSION d1f854ac240ea3928a99294390048e9b2aa6fa0e
On Sat, Dec 23, 2017 at 4:28 PM, kbuild test robot wrote: > > Regressions in current branch: This looks more like some odd compiler regression than a kernel one. Linus
Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot
On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu wrote: > > For testing purposes, I've altered machine_kexec_32.c making the > following toy commit. It naively undoes part of e802a51, solely to > confirm that's where it goes awry in my setup. That's really funky. The idt_invalidate() seems to do *exactly* the same thing. It uses "load_idt()" on an IDT with size 0, and the supplied address. Can you disassemble your "set_idt()" code vs the "idt_invalidate()"? > Is this expected behaviour? No. The code literally seems identical. The only difference is (a) where the 0 limit comes from (b) perhaps build flags and whether it is inlined or not due to being in a different file and neither of those should matter, but maybe they do. Which is why I'd like you to actually look at the generated code and see if you can see any difference.. Linus
Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop
Hi Thomas, At 12/23/2017 09:32 PM, Thomas Gleixner wrote: [...] The BUG_ON panic happens at line 147: BUG_ON(!test_and_clear_bit(bit, cm->alloc_map)); I'm sure Thomas and Dou know it better than me. I'll have a look after the holidays. Merry Christmas! :-) I am trying to look into it. Thanks, dou
Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted
On Sat, Dec 23, 2017 at 10:24 PM, Matthew Wilcox wrote: > On Sat, Dec 23, 2017 at 09:33:40PM -0500, Nick Desaulniers wrote: >> Fixes warnings about shifting unsigned literals being undefined >> behavior. > > Do you mean signed literals? A sorry, s/unsigned/negative signed/g. The warning is: mm/zsmalloc.c:1059:20: warning: shifting a negative signed value is undefined [-Wshift-negative-value] link->next = -1 << OBJ_TAG_BITS; ~~ ^ > >>*/ >> - link->next = -1 << OBJ_TAG_BITS; >> + link->next = -1U << OBJ_TAG_BITS; >> } > > I don't understand what -1U means. Seems like a contradiction in terms, > a negative unsigned number. Is this supposed to be ~0U? $ ag \\-1U[^L] The code base is full of that literal. I think of it as: (unsigned) -1
precedence bug in MAKE_PROCESS_CPUCLOCK macro?
I'm seeing the following warning compiling with Clang: kernel/time/posix-cpu-timers.c:1397:29: warning: shifting a negative signed value is undefined [-Wshift-negative-value] return posix_cpu_clock_get(THREAD_CLOCK, tp); ^~~~ kernel/time/posix-cpu-timers.c:1367:22: note: expanded from macro 'THREAD_CLOCK' #define THREAD_CLOCKMAKE_THREAD_CPUCLOCK(0, CPUCLOCK_SCHED) ^~~ ./include/linux/posix-timers.h:48:2: note: expanded from macro 'MAKE_THREAD_CPUCLOCK' MAKE_PROCESS_CPUCLOCK((tid), (clock) | CPUCLOCK_PERTHREAD_MASK) ^~~ ./include/linux/posix-timers.h:46:23: note: expanded from macro 'MAKE_PROCESS_CPUCLOCK' ((~(clockid_t) (pid) << 3) | (clockid_t) (clock)) ~~ ^ If I understand C's operator precedence rules (http://en.cppreference.com/w/c/language/operator_precedence) correctly, then I suspect the problem is in the sub-expression: (~(clockid_t) (pid) << 3) where pid (an argument to the macro) is first cast to a clockid_t (aka [signed] int), then negated, then shifted by 3 (oops, undefined behavior). Should the result after negation be cast to an unsigned int, or should the left shift happen before negation? CPUCLOCK_PID and CLOCKID_TO_FD seem to shift then negate, but FD_TO_CLOCKID seems to have the same issue as MAKE_PROCESS_CPUCLOCK. Changing the sub-expression to: (~(clockid_t) ((pid) << 3)) changes what it evaluates to. Changing it to: (~(unsigned) (pid) << 3) or ((unsigned) ~(clockid_t) (pid) << 3) or (((unsigned) ~(clockid_t) (pid)) << 3) /* ugly */ does not. I'm happy to send a patch with your suggestion.
Re: [PATCH] zsmalloc: use U suffix for negative literals being shifted
On Sat, Dec 23, 2017 at 09:33:40PM -0500, Nick Desaulniers wrote: > Fixes warnings about shifting unsigned literals being undefined > behavior. Do you mean signed literals? >*/ > - link->next = -1 << OBJ_TAG_BITS; > + link->next = -1U << OBJ_TAG_BITS; > } I don't understand what -1U means. Seems like a contradiction in terms, a negative unsigned number. Is this supposed to be ~0U?
Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG
On Tue, Dec 19, 2017 at 08:17:56PM +0800, Wei Wang wrote:
> +/*
> + * Send balloon pages in sgs to host. The balloon pages are recorded in the
> + * page xbitmap. Each bit in the bitmap corresponds to a page of PAGE_SIZE.
> + * The page xbitmap is searched for continuous "1" bits, which correspond
> + * to continuous pages, to chunk into sgs.
> + *
> + * @page_xb_start and @page_xb_end form the range of bits in the xbitmap that
> + * need to be searched.
> + */
> +static void tell_host_sgs(struct virtio_balloon *vb,
> + struct virtqueue *vq,
> + unsigned long page_xb_start,
> + unsigned long page_xb_end)
I'm not crazy about the naming here. I'd use pfn_min and pfn_max like
you use in the caller.
> +{
> + unsigned long pfn_start, pfn_end;
> + uint32_t max_len = round_down(UINT_MAX, PAGE_SIZE);
> + uint64_t len;
> +
> + pfn_start = page_xb_start;
And I think pfn_start is actually just 'pfn'.
'pfn_end' is perhaps just 'end'. Or 'gap'.
> + while (pfn_start < page_xb_end) {
> + pfn_start = xb_find_set(&vb->page_xb, page_xb_end + 1,
> + pfn_start);
> + if (pfn_start == page_xb_end + 1)
> + break;
> + pfn_end = xb_find_zero(&vb->page_xb, page_xb_end + 1,
> +pfn_start);
> + len = (pfn_end - pfn_start) << PAGE_SHIFT;
> +static inline int xb_set_page(struct virtio_balloon *vb,
> +struct page *page,
> +unsigned long *pfn_min,
> +unsigned long *pfn_max)
> +{
I really don't like it that you're naming things after the 'xb'.
Things should be named by something that makes sense to the user, not
after the particular implementation. If you changed the underlying
representation from an xbitmap to, say, a BTree, you wouldn't want to
rename this function to 'btree_set_page'. Maybe this function is really
"vb_set_page". Or "record_page". Or something. Someone who understands
this driver better than I do can probably weigh in with a better name.
> + unsigned long pfn = page_to_pfn(page);
> + int ret;
> +
> + *pfn_min = min(pfn, *pfn_min);
> + *pfn_max = max(pfn, *pfn_max);
> +
> + do {
> + if (xb_preload(GFP_NOWAIT | __GFP_NOWARN) < 0)
> + return -ENOMEM;
> +
> + ret = xb_set_bit(&vb->page_xb, pfn);
> + xb_preload_end();
> + } while (unlikely(ret == -EAGAIN));
OK, so you don't need a spinlock because you're under a mutex? But you
can't allocate memory because you're in the balloon driver, and so a
GFP_KERNEL allocation might recurse into your driver? Would GFP_NOIO
do the job? I'm a little hazy on exactly how the balloon driver works.
If you can't preload with anything better than that, I think that
xb_set_bit() should attempt an allocation with GFP_NOWAIT | __GFP_NOWARN,
and then you can skip the preload; it has no value for you.
> @@ -173,8 +292,15 @@ static unsigned fill_balloon(struct virtio_balloon *vb,
> size_t num)
>
> while ((page = balloon_page_pop(&pages))) {
> balloon_page_enqueue(&vb->vb_dev_info, page);
> + if (use_sg) {
> + if (xb_set_page(vb, page, &pfn_min, &pfn_max) < 0) {
> + __free_page(page);
> + continue;
> + }
> + } else {
> + set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
> + }
Is this the right behaviour? If we can't record the page in the xb,
wouldn't we rather send it across as a single page?
[PATCH] pid: Handle failure to allocate the first pid in a pid namespace
With the replacement of the pid bitmap and hashtable with an idr in
alloc_pid started occassionally failing when allocating the first pid
in a pid namespace. Things were not completely reset resulting in
the first allocated pid getting the number 2 (not 1). Which
further resulted in ns->proc_mnt not getting set and eventually
causing an oops in proc_flush_task.
Oops: [#1] SMP
CPU: 2 PID: 6743 Comm: trinity-c117 Not tainted 4.15.0-rc4-think+ #2
RIP: 0010:proc_flush_task+0x8e/0x1b0
RSP: 0018:c9000bbffc40 EFLAGS: 00010286
RAX: 0001 RBX: 0001 RCX: fffb
RDX: RSI: c9000bbffc50 RDI:
RBP: c9000bbffc63 R08: R09: 0002
R10: c9000bbffb70 R11: c9000bbffc64 R12: 0003
R13: R14: 0003 R15: 8804c10d7840
FS: 7f7cb8965700() GS:88050a20() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 0003e21ae003 CR4: 001606e0
DR0: 7fb1d6c22000 DR1: DR2:
DR3: DR6: 0ff0 DR7: 0600
Call Trace:
? release_task+0xaf/0x680
release_task+0xd2/0x680
? wait_consider_task+0xb82/0xce0
wait_consider_task+0xbe9/0xce0
? do_wait+0xe1/0x330
do_wait+0x151/0x330
kernel_wait4+0x8d/0x150
? task_stopped_code+0x50/0x50
SYSC_wait4+0x95/0xa0
? rcu_read_lock_sched_held+0x6c/0x80
? syscall_trace_enter+0x2d7/0x340
? do_syscall_64+0x60/0x210
do_syscall_64+0x60/0x210
entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7f7cb82603aa
RSP: 002b:7ffd60770bc8 EFLAGS: 0246
ORIG_RAX: 003d
RAX: ffda RBX: 7f7cb6cd4000 RCX: 7f7cb82603aa
RDX: 000b RSI: 7ffd60770bd0 RDI: 7cca
RBP: 7cca R08: 7f7cb8965700 R09: 7ffd607c7080
R10: R11: 0246 R12:
R13: 7ffd60770bd0 R14: 7f7cb6cd4058 R15: cccd
Code: c1 e2 04 44 8b 60 30 48 8b 40 38 44 8b 34 11 48 c7 c2 60 3a f5 81 44 89
e1 4c 8b 68 58 e8 4b b4 77 00 89 44 24 14 48 8d 74 24 10 <49> 8b 7d 00 e8 b9 6a
f9 ff 48 85 c0 74 1a 48 89 c7 48 89 44 24
RIP: proc_flush_task+0x8e/0x1b0 RSP: c9000bbffc40
CR2:
---[ end trace 53d67a6481059862 ]---
Improve the quality of the implementation by resetting the place to
start allocating pids on failure to allocate the first pid.
As improving the quality of the implementation is the goal remove the now
unnecesarry disable_pid_allocations call when we fail to mount proc.
Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR API")
Fixes: 8ef047aaaeb8 ("pid namespaces: make alloc_pid(), free_pid() and
put_pid() work with struct upid")
Reported-by: Dave Jones
Signed-off-by: "Eric W. Biederman"
---
I have tested this by forcing an allocation failure after allocating pid
1, and the symptoms are identical to what Dave Jones has observed.
I have further confirmed that this change causes the failure to go away.
If no one objects I will send a pull request to Linus in the next day or two.
kernel/pid.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/kernel/pid.c b/kernel/pid.c
index b13b624e2c49..1e8bb6550ec4 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -193,10 +193,8 @@ struct pid *alloc_pid(struct pid_namespace *ns)
}
if (unlikely(is_child_reaper(pid))) {
- if (pid_ns_prepare_proc(ns)) {
- disable_pid_allocation(ns);
+ if (pid_ns_prepare_proc(ns))
goto out_free;
- }
}
get_pid_ns(ns);
@@ -226,6 +224,10 @@ struct pid *alloc_pid(struct pid_namespace *ns)
while (++i <= ns->level)
idr_remove(&ns->idr, (pid->numbers + i)->nr);
+ /* On failure to allocate the first pid, reset the state */
+ if (ns->pid_allocated == PIDNS_ADDING)
+ idr_set_cursor(&ns->idr, 0);
+
spin_unlock_irq(&pidmap_lock);
kmem_cache_free(ns->pid_cachep, pid);
--
2.14.1
Re: [TEST PATCH] pid: fix allocating pid 2 for init (was Re: proc_flush_task oops)
Alexey Dobriyan writes: > On Fri, Dec 22, 2017 at 08:41:54AM -0600, Eric W. Biederman wrote: >> Alexey Dobriyan writes: > >> > unshare >> > fork >> > alloc_pid in level 1 succeeds >> > alloc_pid in level 0 fails, ->idr_next is 2 >> > fork >> > alloc pid 2 >> > exit >> > >> > Reliable reproducer and fail injection patch attached >> > >> > I'd say proper fix is allocating pids in the opposite order >> > so that failure in the last layer doesn't move IDR cursor >> > in baby child pidns. >> >> I agree with you about changing the order. That will make >> the code simpler and in the second loop actually conforming C code, >> and fix the immediate problem. > > Something like that (barely tested) I have thought about this some more and I think we can do better. I don't like the on stack pid_ns array. The only reason the code calls disable_pid_allocation is that we don't handle this error. The semantics of least surprise, are that if we run out of resources while allocating something, trying again when more resources are available will make it work. So it looks like handling the error will improve the quality of the implemenation, and be a simpler, less dangerous patch. diff --git a/kernel/pid.c b/kernel/pid.c --- a/kernel/pid.c +++ b/kernel/pid.c @@ -226,6 +224,10 @@ struct pid *alloc_pid(struct pid_namespace *ns) while (++i <= ns->level) idr_remove(&ns->idr, (pid->numbers + i)->nr); + /* On failure to allocate the first pid, reset the state */ + if (ns->pid_allocated == PIDNS_ADDING) + idr_set_cursor(&ns->idr, 0); + spin_unlock_irq(&pidmap_lock); kmem_cache_free(ns->pid_cachep, pid); Eric
[PATCH] x86/xen/time: fix section mismatch for xen_init_time_ops()
The header declares this function as __init but is defined in __ref section. Signed-off-by: Nick Desaulniers --- arch/x86/xen/xen-ops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h index 75011b8..3b34745 100644 --- a/arch/x86/xen/xen-ops.h +++ b/arch/x86/xen/xen-ops.h @@ -72,7 +72,7 @@ u64 xen_clocksource_read(void); void xen_setup_cpu_clockevents(void); void xen_save_time_memory_area(void); void xen_restore_time_memory_area(void); -void __init xen_init_time_ops(void); +void __ref xen_init_time_ops(void); void __init xen_hvm_init_time_ops(void); irqreturn_t xen_debug_interrupt(int irq, void *dev_id); -- 2.7.4
[PATCH] zsmalloc: use U suffix for negative literals being shifted
Fixes warnings about shifting unsigned literals being undefined behavior. Signed-off-by: Nick Desaulniers --- mm/zsmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 685049a..5d31458 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1056,7 +1056,7 @@ static void init_zspage(struct size_class *class, struct zspage *zspage) * Reset OBJ_TAG_BITS bit to last link to tell * whether it's allocated object or not. */ - link->next = -1 << OBJ_TAG_BITS; + link->next = -1U << OBJ_TAG_BITS; } kunmap_atomic(vaddr); page = next_page; -- 2.7.4
[PATCH] objtool: fix enum-conversion warning
When compiling with Clang, the following warning is observed: CC tools/objtool/arch/x86/decode.o arch/x86/decode.c:141:20: error: implicit conversion from enumeration type 'enum op_src_type' to different enumeration type 'enum op_dest_type' [-Werror,-Wenum-conversion] op->dest.type = OP_SRC_REG; ~ ^~ Signed-off-by: Nick Desaulniers --- tools/objtool/arch/x86/decode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c index 8acfc47..540a209 100644 --- a/tools/objtool/arch/x86/decode.c +++ b/tools/objtool/arch/x86/decode.c @@ -138,7 +138,7 @@ int arch_decode_instruction(struct elf *elf, struct section *sec, *type = INSN_STACK; op->src.type = OP_SRC_ADD; op->src.reg = op_to_cfi_reg[modrm_reg][rex_r]; - op->dest.type = OP_SRC_REG; + op->dest.type = OP_DEST_REG; op->dest.reg = CFI_SP; } break; -- 2.7.4
Re: linux/master crashes on boot with KASAN=y
On Sat, Dec 23, 2017 at 4:41 AM, Andrey Ryabinin
wrote:
> On 12/23/2017 11:01 AM, Jakub Kicinski wrote:
>> Hi!
>>
>> I bisected a crash on boot to this:
>>
>> commit 21506525fb8ddb0342f2a2370812d47f6a1f3833 (HEAD, refs/bisect/bad)
>> Author: Andy Lutomirski
>> Date: Mon Dec 4 15:07:16 2017 +0100
>>
>> x86/kasan/64: Teach KASAN about the cpu_entry_area
>
>
> Thanks.
> There is nothing wrong with this patch, it just uncovered older bug.
> The actual problem comes from f06bdd4001c2 ("x86/mm: Adapt MODULES_END based
> on fixmap section size")
> which is made kasan_mem_to_shadow(MODULES_END) potentially unaligned to page
> boundary.
> And when we feed unaligned address to kasan_populate_zero_shadow() it doesn't
> do the right thing.
>
> Could you tell me if the fix bellow works for you?
>
> ---
> arch/x86/include/asm/kasan.h| 8
> arch/x86/include/asm/pgtable_64_types.h | 4 +++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
> index b577dd0916aa..0c580e4b2ccc 100644
> --- a/arch/x86/include/asm/kasan.h
> +++ b/arch/x86/include/asm/kasan.h
> @@ -5,6 +5,14 @@
> #include
> #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
>
> +#ifndef KASAN_SHADOW_SCALE_SHIFT
> +# ifdef CONFIG_KASAN
> +# define KASAN_SHADOW_SCALE_SHIFT 3
> +# else
> +# define KASAN_SHADOW_SCALE_SHIFT 0
> +# endif
> +#endif
> +
> /*
> * Compiler uses shadow offset assuming that addresses start
> * from 0. Kernel addresses don't start from 0, so shadow
> diff --git a/arch/x86/include/asm/pgtable_64_types.h
> b/arch/x86/include/asm/pgtable_64_types.h
> index 6d5f45dcd4a1..d34a90d6c374 100644
> --- a/arch/x86/include/asm/pgtable_64_types.h
> +++ b/arch/x86/include/asm/pgtable_64_types.h
> @@ -6,6 +6,7 @@
>
> #ifndef __ASSEMBLY__
> #include
> +#include
> #include
>
> /*
> @@ -96,7 +97,8 @@ typedef struct { pteval_t pte; } pte_t;
> #define VMALLOC_END(VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
> #define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
> /* The module sections ends with the start of the fixmap */
> -#define MODULES_END __fix_to_virt(__end_of_fixed_addresses + 1)
> +#define MODULES_END (__fix_to_virt(__end_of_fixed_addresses + 1) & \
> + ~((PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT) - 1))
Could this be #define MODULES_END KASAN_ROUND_DOWN(__fix_to_virt(...)) instead?
PROBLEM: consolidated IDT invalidation causes kexec to reboot
Short description: loading a crash kernel with (a) kexec -l [..] or
(b) kexec -p [..] and then testing it with (a) kexec -e or (b) echo c
> /proc/sysrq-trigger results in a regular reboot (going through BIOS,
etc.).
The commit that starts exhibiting this behaviour for me is
e802a51: x86/idt: Consolidate IDT invalidation
with its parent 8f55868 behaving normally (in scenarios (a) and (b)
alike; (b) produces /proc/vmcore, etc.).
For testing purposes, I've altered machine_kexec_32.c making the
following toy commit. It naively undoes part of e802a51, solely to
confirm that's where it goes awry in my setup.
--
machine_kexec calls set_idt instead of idt_invalidate for testing purposes
diff --git a/arch/x86/kernel/machine_kexec_32.c
b/arch/x86/kernel/machine_kexec_32.c
index 00bc751..70f7d05 100644
--- a/arch/x86/kernel/machine_kexec_32.c
+++ b/arch/x86/kernel/machine_kexec_32.c
@@ -26,6 +26,19 @@
#include
#include
+
+
+static void set_idt(void *newidt, __u16 limit)
+{
+ struct desc_ptr curidt;
+
+ /* ia32 supports unaliged loads & stores */
+ curidt.size= limit;
+ curidt.address = (unsigned long)newidt;
+
+ load_idt(&curidt);
+}
+
static void set_gdt(void *newgdt, __u16 limit)
{
struct desc_ptr curgdt;
@@ -233,7 +246,7 @@ void machine_kexec(struct kimage *image)
* If you want to load them you must set up your own idt & gdt.
*/
set_gdt(phys_to_virt(0), 0);
- idt_invalidate(phys_to_virt(0));
+ set_idt(phys_to_virt(0), 0);
/* now call it */
image->start = relocate_kernel_ptr((unsigned long)image->head
--
The kernel compiled with these changes restores kexec functionality on
the machine I'm trying it on:
ASUS F5RL Core(TM)2 Duo CPU T5450 @ 1.66GHz
on Debian stable 9.3 32 bit. The loading command I use:
kexec [-l|-p] /boot/dump/vmlinuz-4.14.8-dump
--initrd=/boot/dump/initrd.img-4.14.8-dump --append="root=/dev/sda1 1 irqpoll
nr_cpus=1 reset_devices"
The nr_cpus=1 is a remnant I left in there; the dump kernel is an
SMP-disabled version of the latest stable one (4.14.8).
Is this expected behaviour?
The issue emerged while reporting a CPU lockup in another email
thread; as this seems different, I figured it wouldn't hurt to send
out a separate message.
Thank you.
Re: [PATCH 4.4 00/78] 4.4.108-stable review
On 12/22/2017 12:45 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.108 release. There are 78 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Dec 24 08:45:30 UTC 2017. Anything received after that time might be too late. For v4.4.107-79-g0989207: Build results: total: 145 pass: 144 fail: 1 Failed builds: alpha:allmodconfig Qemu test results: total: 118 pass: 118 fail: 0 The alpha fix is missing from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git branch linux-4.4.y; it points to the same sha. Guenter
Re: [patch 0/4] timer/nohz: Fix timer/nohz woes
On Sat, Dec 23, 2017 at 05:21:20PM -0800, Paul E. McKenney wrote: > On Fri, Dec 22, 2017 at 09:09:07AM -0800, Paul E. McKenney wrote: > > On Fri, Dec 22, 2017 at 03:51:11PM +0100, Thomas Gleixner wrote: > > > Paul was observing weird stalls which are hard to reproduce and decode. We > > > were finally able to reproduce and decode the wreckage on RT. > > > > > > The following series addresses the issues and hopefully nails the root > > > cause completely. > > > > > > Please review carefully and expose it to the dreaded rcu torture tests > > > which seem to be the only way to trigger it. > > > > Best Christmas present ever, thank you!!! > > > > Just started up three concurrent 10-hour runs of the infamous rcutorture > > TREE01 scenario, and will let you know how it goes! > > Well, I messed up the first test and then reran it. Which had the benefit > of giving me a baseline. The rerun (with all four patches) produced > failures, so I ran it again with an additional patch of mine. I score > these tests by recording the time at first failure, or, if there is no > failure, the duration of the test. Summing the values gives the score. > And here are the scores, where 30 is a perfect score: Sigh. They were five-hour tests, not ten-hour tests. 1. Baseline: 3.0+2.5+5=10.5 2. Four patches from Anna-Marie and Thomas: 5+2.7+1.7=9.4 3. Ditto plus the patch below: 5+4.3+5=14.3 Oh, and the reason for my suspecting that #2 is actually an improvement over #1 is that my patch by itself produced a very small improvement in reliability. This leads to the hypothesis that #2 really is helping out in some way or another. Thanx, Paul > 1.Baseline: 3.0+2.5+10=15.5 > > 2.Four patches from Anna-Marie and Thomas: 10+2.7+1.7=14.4 > > 3.Ditto plus the patch below: 10+4.3+10=24.3 > > Please note that these are nowhere near anything even resembling > statistical significance. However, they are encouraging. I will do > more runs, but also do shorter five-hour runs to increase the amount > of data per unit time. Please note also that my patch by itself never > did provide that great of an improvement, so there might be some sort > of combination effect going on here. Or maybe it is just luck, who knows? > > Please note that I have not yet ported my diagnostic patches on top of > these, however, the stacks have the usual schedule_timeout() entries. > This is not too surprising from a software-engineering viewpoint: > Locating several bugs at a given point of time usually indicates that > there are more to be found. So in a sense we are lucky that the > same test triggers at least one of those additional bugs. > > Thanx, Paul > > > > commit accb0edb85526a05b934eac49658d05ea0216fc4 > Author: Paul E. McKenney > Date: Thu Dec 7 13:18:44 2017 -0800 > > timers: Ensure that timer_base ->clk accounts for time offline > > The timer_base ->must_forward_clk is set to indicate that the next timer > operation on that timer_base must check for passage of time. One instance > of time passage is when the timer wheel goes idle, and another is when > the corresponding CPU is offline. Note that it is not appropriate to set > ->is_idle because that could result in IPIing an offline CPU. Therefore, > this commit instead sets ->must_forward_clk at CPU-offline time. > > Signed-off-by: Paul E. McKenney > > diff --git a/kernel/time/timer.c b/kernel/time/timer.c > index ffebcf878fba..94cce780c574 100644 > --- a/kernel/time/timer.c > +++ b/kernel/time/timer.c > @@ -1875,6 +1875,7 @@ int timers_dead_cpu(unsigned int cpu) > > BUG_ON(old_base->running_timer); > > + old_base->must_forward_clk = true; > for (i = 0; i < WHEEL_SIZE; i++) > migrate_timer_list(new_base, old_base->vectors + i); >
Re: linux/master crashes on boot with KASAN=y
On Sat, 23 Dec 2017 15:41:27 +0300, Andrey Ryabinin wrote:
> On 12/23/2017 11:01 AM, Jakub Kicinski wrote:
> > Hi!
> >
> > I bisected a crash on boot to this:
> >
> > commit 21506525fb8ddb0342f2a2370812d47f6a1f3833 (HEAD, refs/bisect/bad)
> > Author: Andy Lutomirski
> > Date: Mon Dec 4 15:07:16 2017 +0100
> >
> > x86/kasan/64: Teach KASAN about the cpu_entry_area
>
>
> Thanks.
> There is nothing wrong with this patch, it just uncovered older bug.
> The actual problem comes from f06bdd4001c2 ("x86/mm: Adapt MODULES_END based
> on fixmap section size")
> which is made kasan_mem_to_shadow(MODULES_END) potentially unaligned to page
> boundary.
> And when we feed unaligned address to kasan_populate_zero_shadow() it doesn't
> do the right thing.
>
> Could you tell me if the fix bellow works for you?
Works for me, thank you!
Tested-by: Jakub Kicinski
> arch/x86/include/asm/kasan.h| 8
> arch/x86/include/asm/pgtable_64_types.h | 4 +++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
> index b577dd0916aa..0c580e4b2ccc 100644
> --- a/arch/x86/include/asm/kasan.h
> +++ b/arch/x86/include/asm/kasan.h
> @@ -5,6 +5,14 @@
> #include
> #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
>
> +#ifndef KASAN_SHADOW_SCALE_SHIFT
> +# ifdef CONFIG_KASAN
> +# define KASAN_SHADOW_SCALE_SHIFT 3
> +# else
> +# define KASAN_SHADOW_SCALE_SHIFT 0
> +# endif
> +#endif
> +
> /*
> * Compiler uses shadow offset assuming that addresses start
> * from 0. Kernel addresses don't start from 0, so shadow
> diff --git a/arch/x86/include/asm/pgtable_64_types.h
> b/arch/x86/include/asm/pgtable_64_types.h
> index 6d5f45dcd4a1..d34a90d6c374 100644
> --- a/arch/x86/include/asm/pgtable_64_types.h
> +++ b/arch/x86/include/asm/pgtable_64_types.h
> @@ -6,6 +6,7 @@
>
> #ifndef __ASSEMBLY__
> #include
> +#include
> #include
>
> /*
> @@ -96,7 +97,8 @@ typedef struct { pteval_t pte; } pte_t;
> #define VMALLOC_END (VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
> #define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
> /* The module sections ends with the start of the fixmap */
> -#define MODULES_END __fix_to_virt(__end_of_fixed_addresses + 1)
> +#define MODULES_END (__fix_to_virt(__end_of_fixed_addresses + 1) & \
> + ~((PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT) - 1))
> #define MODULES_LEN (MODULES_END - MODULES_VADDR)
> #define ESPFIX_PGD_ENTRY _AC(-2, UL)
> #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << P4D_SHIFT)
Re: [patch 0/4] timer/nohz: Fix timer/nohz woes
On Fri, Dec 22, 2017 at 09:09:07AM -0800, Paul E. McKenney wrote: > On Fri, Dec 22, 2017 at 03:51:11PM +0100, Thomas Gleixner wrote: > > Paul was observing weird stalls which are hard to reproduce and decode. We > > were finally able to reproduce and decode the wreckage on RT. > > > > The following series addresses the issues and hopefully nails the root > > cause completely. > > > > Please review carefully and expose it to the dreaded rcu torture tests > > which seem to be the only way to trigger it. > > Best Christmas present ever, thank you!!! > > Just started up three concurrent 10-hour runs of the infamous rcutorture > TREE01 scenario, and will let you know how it goes! Well, I messed up the first test and then reran it. Which had the benefit of giving me a baseline. The rerun (with all four patches) produced failures, so I ran it again with an additional patch of mine. I score these tests by recording the time at first failure, or, if there is no failure, the duration of the test. Summing the values gives the score. And here are the scores, where 30 is a perfect score: 1. Baseline: 3.0+2.5+10=15.5 2. Four patches from Anna-Marie and Thomas: 10+2.7+1.7=14.4 3. Ditto plus the patch below: 10+4.3+10=24.3 Please note that these are nowhere near anything even resembling statistical significance. However, they are encouraging. I will do more runs, but also do shorter five-hour runs to increase the amount of data per unit time. Please note also that my patch by itself never did provide that great of an improvement, so there might be some sort of combination effect going on here. Or maybe it is just luck, who knows? Please note that I have not yet ported my diagnostic patches on top of these, however, the stacks have the usual schedule_timeout() entries. This is not too surprising from a software-engineering viewpoint: Locating several bugs at a given point of time usually indicates that there are more to be found. So in a sense we are lucky that the same test triggers at least one of those additional bugs. Thanx, Paul commit accb0edb85526a05b934eac49658d05ea0216fc4 Author: Paul E. McKenney Date: Thu Dec 7 13:18:44 2017 -0800 timers: Ensure that timer_base ->clk accounts for time offline The timer_base ->must_forward_clk is set to indicate that the next timer operation on that timer_base must check for passage of time. One instance of time passage is when the timer wheel goes idle, and another is when the corresponding CPU is offline. Note that it is not appropriate to set ->is_idle because that could result in IPIing an offline CPU. Therefore, this commit instead sets ->must_forward_clk at CPU-offline time. Signed-off-by: Paul E. McKenney diff --git a/kernel/time/timer.c b/kernel/time/timer.c index ffebcf878fba..94cce780c574 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -1875,6 +1875,7 @@ int timers_dead_cpu(unsigned int cpu) BUG_ON(old_base->running_timer); + old_base->must_forward_clk = true; for (i = 0; i < WHEEL_SIZE; i++) migrate_timer_list(new_base, old_base->vectors + i);
Legitimate !!!
Hi linux-kernel@vger.kernel.org , Can work to-gether legally ? . IF YES for more info email ( chen.ya...@yandex.com )
[linus:master] BUILD REGRESSION d1f854ac240ea3928a99294390048e9b2aa6fa0e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
branch HEAD: d1f854ac240ea3928a99294390048e9b2aa6fa0e Merge branch
'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Regressions in current branch:
arch/c6x/platforms/plldata.c:279:33: error: implicit declaration of function
'get_coreid'; did you mean 'get_order'? [-Werror=implicit-function-declaration]
drivers/tty/serial/8250/8250_core.c:1094:1: error: unrecognizable insn:
drivers/tty/serial/8250/8250_core.c:1094:1: internal compiler error: in
extract_insn, at recog.c:2311
fs//xfs/xfs_ioctl.c:1624:1: internal compiler error: in change_address_1, at
emit-rtl.c:2150
fs/xfs/xfs_ioctl.c:1629:1: internal compiler error: in change_address_1, at
emit-rtl.c:2150
Please submit a full bug report,
{standard input}:1226: Error: displacement to undefined symbol .L329 overflows
12-bit field
{standard input}:1233: Error: displacement to undefined symbol .L331 overflows
12-bit field
{standard input}:1253: Error: displacement to undefined symbol .L359 overflows
12-bit field
{standard input}:1278: Error: displacement to undefined symbol .L360 overflows
12-bit field
{standard input}:1405: Error: displacement to undefined symbol .L255 overflows
12-bit field
{standard input}:1408: Error: invalid operands for opcode
{standard input}:1408: Error: missing operand
{standard input}:1453: Error: displacement to undefined symbol .L285 overflows
12-bit field
{standard input}:1457: Error: displacement to undefined symbol .L286 overflows
12-bit field
{standard input}:1467: Error: displacement to undefined symbol .L257 overflows
12-bit field
{standard input}:1893: Error: displacement to undefined symbol .L229 overflows
12-bit field
{standard input}:199: Error: unknown opcode
{standard input}:2013: Error: displacement to undefined symbol .L235 overflows
12-bit field
{standard input}:9613: Error: invalid operands for opcode
{standard input}:9613: Error: missing operand
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
verifier.c:(.text+0x31ec): undefined reference to `__multi3'
Error ids grouped by kconfigs:
recent_errors
├── c6x-evmc6472_defconfig
│ └──
arch-c6x-platforms-plldata.c:error:implicit-declaration-of-function-get_coreid-did-you-mean-get_order
├── cris-allyesconfig
│ ├── drivers-tty-serial-8250_core.c:error:unrecognizable-insn:
│ └──
drivers-tty-serial-8250_core.c:internal-compiler-error:in-extract_insn-at-recog.c
├── mips-64r6el_defconfig
│ └── verifier.c:(.text):undefined-reference-to-__multi3
├── sh-allyesconfig
│ ├──
fs-xfs-xfs_ioctl.c:internal-compiler-error:in-change_address_1-at-emit-rtl.c
│ ├── Please-submit-a-full-bug-report
│ ├──
standard-input:Error:displacement-to-undefined-symbol-.L229-overflows-bit-field
│ ├──
standard-input:Error:displacement-to-undefined-symbol-.L235-overflows-bit-field
│ ├── standard-input:Error:invalid-operands-for-opcode
│ ├── standard-input:Error:missing-operand
│ └──
standard-input:Error:open-CFI-at-the-end-of-file-missing-.cfi_endproc-directive
├── sh-j2_defconfig
│ └── standard-input:Error:unknown-opcode
├── sh-sdk7786_defconfig
│ ├──
standard-input:Error:displacement-to-undefined-symbol-.L255-overflows-bit-field
│ ├──
standard-input:Error:displacement-to-undefined-symbol-.L257-overflows-bit-field
│ ├──
standard-input:Error:displacement-to-undefined-symbol-.L285-overflows-bit-field
│ └──
standard-input:Error:displacement-to-undefined-symbol-.L286-overflows-bit-field
└── sh-titan_defconfig
├──
fs-xfs-xfs_ioctl.c:internal-compiler-error:in-change_address_1-at-emit-rtl.c
├── Please-submit-a-full-bug-report
├──
standard-input:Error:displacement-to-undefined-symbol-.L329-overflows-bit-field
├──
standard-input:Error:displacement-to-undefined-symbol-.L331-overflows-bit-field
├──
standard-input:Error:displacement-to-undefined-symbol-.L359-overflows-bit-field
├──
standard-input:Error:displacement-to-undefined-symbol-.L360-overflows-bit-field
├── standard-input:Error:invalid-operands-for-opcode
└── standard-input:Error:missing-operand
elapsed time: 155m
configs tested: 144
x86_64 acpi-redef
x86_64 allyesdebian
x86_64nfsroot
i386 tinyconfig
i386 randconfig-x016-201752
i386 randconfig-x011-201752
i386 randconfig-x014-201752
i386 randconfig-x017-201752
i386 randconfig-x019-201752
i386 randconfig-x018-201752
i386 randconfig-x010-201752
i386 randconfig-x013-201752
i386 randconfig-x012-201752
i386 randconfig-x015-201752
i386 randconfig-n0-201752
x86_64 randconfig-x003-201752
x86_64 randconfig-x002-201752
x86_6
Re: [PATCH v5 3/6] cx25840: add pin to pad mapping and output format configuration
On 23.12.2017 15:08, Philippe Ombredanne wrote: > On Sat, Dec 23, 2017 at 12:18 AM, Maciej S. Szmigiero > wrote: >> This commit adds pin to pad mapping and output format configuration support >> in CX2584x-series chips to cx25840 driver. >> >> This functionality is then used to allow disabling ivtv-specific hacks >> (called a "generic mode"), so cx25840 driver can be used for other devices >> not needing them without risking compatibility problems. >> >> Signed-off-by: Maciej S. Szmigiero >> --- >> drivers/media/i2c/cx25840/cx25840-core.c | 396 >> ++- >> drivers/media/i2c/cx25840/cx25840-core.h | 13 + >> drivers/media/i2c/cx25840/cx25840-vbi.c | 3 + >> include/media/drv-intf/cx25840.h | 74 +- >> 4 files changed, 484 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/media/i2c/cx25840/cx25840-core.c >> b/drivers/media/i2c/cx25840/cx25840-core.c >> index 2189980a0f29..e2fd33a64550 100644 >> --- a/drivers/media/i2c/cx25840/cx25840-core.c >> +++ b/drivers/media/i2c/cx25840/cx25840-core.c >> @@ -21,6 +21,9 @@ >> * CX23888 DIF support for the HVR1850 >> * Copyright (C) 2011 Steven Toth >> * >> + * CX2584x pin to pad mapping and output format configuration support are >> + * Copyright (C) 2011 Maciej S. Szmigiero >> + * >> * This program is free software; you can redistribute it and/or >> * modify it under the terms of the GNU General Public License >> * as published by the Free Software Foundation; either version 2 > > Since you are touching the copyright here, I wonder if you could reach > out to other copyright holders and switch to using an SPDX tag > instead? > Well, I'm really just adding two functionalities to the cx25840 driver, which consist of 6 additional files besides "cx25840-core.c". All this code is mostly written by other people, in addition to this there is also a note at the top of this file that the driver is "[b]ased on the saa7115 driver and on the first version of Chris Kennedy's cx25840 driver". Since of 119 *.c files in drivers/media/i2c/ directory only 3 already have SPDX tags the rest will (probably) be amended with this tag anyway, and that's when the cx25840 driver can also be tagged, using an appropriate process for this (IANAL). > -- > Cordially > Philippe Ombredanne Best regards, Maciej Szmigiero
Re: [PATCH 4.9 000/104] 4.9.72-stable review
On 12/22/2017 12:45 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.72 release. There are 104 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Dec 24 08:45:33 UTC 2017. Anything received after that time might be too late. For v4.9.71-109-g7a93fd0: Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 126 pass: 126 fail: 0 Guenter
Re: [PATCH 4.14 000/159] 4.14.9-stable review
On 12/22/2017 12:44 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late. For v4.14.8-176-g3b153f8: Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 126 pass: 126 fail: 0 Guenter
[PATCH 3/3] pinctrl: rockchip: Fix a typo in four comment lines
From: Markus Elfring
Date: Sat, 23 Dec 2017 22:22:54 +0100
Adjust words in these descriptions.
Signed-off-by: Markus Elfring
---
drivers/pinctrl/pinctrl-rockchip.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index 5e76a6d8a1cb..1cd85411e906 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -136,7 +136,7 @@ struct rockchip_drv {
* @iomux: array describing the 4 iomux sources of the bank
* @drv: array describing the 4 drive strength sources of the bank
* @pull_type: array describing the 4 pull type sources of the bank
- * @valid: are all necessary informations present
+ * @valid: is all necessary information present
* @of_node: dt node of this bank
* @drvdata: common pinctrl basedata
* @domain: irqdomain of the gpio bank
@@ -1988,7 +1988,7 @@ static int rockchip_pmx_set(struct pinctrl_dev *pctldev,
unsigned selector,
info->functions[selector].name, info->groups[group].name);
/*
-* for each pin in the pin group selected, program the correspoding pin
+* for each pin in the pin group selected, program the corresponding
* pin function number in the config register.
*/
for (cnt = 0; cnt < info->groups[group].npins; cnt++) {
@@ -2527,7 +2527,7 @@ static int rockchip_gpio_get(struct gpio_chip *gc,
unsigned offset)
/*
* gpiolib gpio_direction_input callback function. The setting of the pin
- * mux function as 'gpio input' will be handled by the pinctrl susbsystem
+ * mux function as 'gpio input' will be handled by the pinctrl subsystem
* interface.
*/
static int rockchip_gpio_direction_input(struct gpio_chip *gc, unsigned offset)
@@ -2537,7 +2537,7 @@ static int rockchip_gpio_direction_input(struct gpio_chip
*gc, unsigned offset)
/*
* gpiolib gpio_direction_output callback function. The setting of the pin
- * mux function as 'gpio output' will be handled by the pinctrl susbsystem
+ * mux function as 'gpio output' will be handled by the pinctrl subsystem
* interface.
*/
static int rockchip_gpio_direction_output(struct gpio_chip *gc,
--
2.15.1
[PATCH 2/3] pinctrl: rockchip: Improve a size determination in rockchip_pinctrl_probe()
From: Markus Elfring Date: Sat, 23 Dec 2017 22:07:30 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/pinctrl/pinctrl-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c index 285169170eb2..5e76a6d8a1cb 100644 --- a/drivers/pinctrl/pinctrl-rockchip.c +++ b/drivers/pinctrl/pinctrl-rockchip.c @@ -3158,7 +3158,7 @@ static int rockchip_pinctrl_probe(struct platform_device *pdev) return -ENODEV; } - info = devm_kzalloc(dev, sizeof(struct rockchip_pinctrl), GFP_KERNEL); + info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL); if (!info) return -ENOMEM; -- 2.15.1
[PATCH 1/3] pinctrl: rockchip: Delete error messages for a failed memory allocation in two functions
From: Markus Elfring
Date: Sat, 23 Dec 2017 22:02:47 +0100
Omit extra messages for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/pinctrl/pinctrl-rockchip.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index 2ba17548ad5b..285169170eb2 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -2400,18 +2400,14 @@ static int rockchip_pinctrl_parse_dt(struct
platform_device *pdev,
info->functions = devm_kzalloc(dev, info->nfunctions *
sizeof(struct rockchip_pmx_func),
GFP_KERNEL);
- if (!info->functions) {
- dev_err(dev, "failed to allocate memory for function list\n");
+ if (!info->functions)
return -EINVAL;
- }
info->groups = devm_kzalloc(dev, info->ngroups *
sizeof(struct rockchip_pin_group),
GFP_KERNEL);
- if (!info->groups) {
- dev_err(dev, "failed allocate memory for ping group list\n");
+ if (!info->groups)
return -EINVAL;
- }
i = 0;
@@ -2447,10 +2443,9 @@ static int rockchip_pinctrl_register(struct
platform_device *pdev,
pindesc = devm_kzalloc(&pdev->dev, sizeof(*pindesc) *
info->ctrl->nr_pins, GFP_KERNEL);
- if (!pindesc) {
- dev_err(&pdev->dev, "mem alloc for pin descriptors failed\n");
+ if (!pindesc)
return -ENOMEM;
- }
+
ctrldesc->pins = pindesc;
ctrldesc->npins = info->ctrl->nr_pins;
--
2.15.1
[PATCH 0/3] Pinctrl-Rockchip: Adjustments for six functions
From: Markus Elfring Date: Sat, 23 Dec 2017 22:33:44 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete error messages for a failed memory allocation in two functions Improve a size determination in rockchip_pinctrl_probe() Fix a typo in four comment lines drivers/pinctrl/pinctrl-rockchip.c | 23 +-- 1 file changed, 9 insertions(+), 14 deletions(-) -- 2.15.1
Re: [PATCH 4.4 00/78] 4.4.108-stable review
On 12/23/2017 08:26 AM, Greg Kroah-Hartman wrote:
On Sat, Dec 23, 2017 at 08:13:48AM -0800, Guenter Roeck wrote:
On 12/23/2017 06:46 AM, Greg Kroah-Hartman wrote:
On Sat, Dec 23, 2017 at 10:19:32AM +0100, Greg Kroah-Hartman wrote:
On Fri, Dec 22, 2017 at 10:18:31AM -0800, Guenter Roeck wrote:
On Fri, Dec 22, 2017 at 09:45:41AM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.108 release.
There are 78 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Dec 24 08:45:30 UTC 2017.
Anything received after that time might be too late.
I lost track with versions. This is with v4.4.107-79-g0989207.
Build results:
total: 145 pass: 144 fail: 1
Failed builds:
alpha:allmodconfig
Qemu test results:
total: 118 pass: 118 fail: 0
alpha/include/asm/mmu_context.h: In function 'ev5_switch_mm':
arch/alpha/include/asm/mmu_context.h:158:2: error: implicit declaration of
function 'task_thread_info'
arch/alpha/include/asm/mmu_context.h:158:24: error: invalid type argument of
'->' (have 'int')
alpha/include/asm/mmu_context.h: In function 'init_new_context':
arch/alpha/include/asm/mmu_context.h:236:24: error: invalid type argument of
'->' (have 'int')
arch/alpha/include/asm/mmu_context.h: In function 'enter_lazy_tlb':
arch/alpha/include/asm/mmu_context.h:250:23: error: invalid type argument of
'->' (have 'int')
Didn't I already report this ?
I thought that was a 4.9 issue. Let me look into this later today,
thanks for the report...
Hm, yeah, looks to be the same issue that 4.9 had. I resolve that by
ripping out the whole series, which I don't want to do here. Let me see
if I can resolve it simpler...
Apply 8ee912dab95f ("alpha: fix build failures") and fix conflict by picking
the new include files. I am currently rebuilding with that applied to ensure
that it breaks nothing else.
Now added, and pushed out, let me know how that goes.
Are you sure that you pushed it into the git repository ?
Turns out my builders didn't pick it up, not even when I tried manually.
Guenter
My Beloved
Hello Dear, Please forgive me for stressing you with my predicaments as I know that this letter may come to you as big surprise. Actually, I came across your E-mail from my personal search afterward I decided to email you directly believing that you will be honest to fulfill my final wish before i die. Meanwhile, I am MRS KADI, 62 years old, from France, and I am suffering from a long time cancer and from all indication my condition is really deteriorating as my doctors have confirmed and courageously Advised me that I may not live beyond two months from now for the reason that my tumor has reached a critical stage which has defiled all forms of medical treatment, As a matter of fact, registered nurse by profession while my husband was dealing on Gold Dust and Gold Dory Bars in Burkina Faso till his sudden death the year 2008 then I took over his business till date. In fact, at this moment I have a deposit sum of four million five hundred thousand US dollars [$4,500,000.00] with one of the leading bank in Burkina Faso but unfortunately I cannot visit the bank since I’m critically sick and powerless to do anything myself but my bank account officer advised me to assign any of my trustworthy relative, friends or partner with authorization letter to stand as the recipient of my money but sorrowfully I don’t have any reliable relative and no child. Therefore, I want you to receive the money and take 50% to take care of yourself and family while 50% should be use basically on humanitarian purposes mostly to orphanages home, Motherless babies home, less privileged and disable citizens and widows around the world. And as soon as I receive your respond I shall send you the full details with my pictures, banking records and with full contacts of my banking institution to communicate them on the matter. Hope to hear from you soon. Yours Faithfully, MRS KADI hello
Re: BUG: unable to handle kernel NULL pointer dereference in irq_may_run
On Fri, Dec 22, 2017 at 08:13:47PM +0100, Thomas Gleixner wrote: > On Thu, 21 Dec 2017, syzbot wrote: > > > Hello, > > > > syzkaller hit the following crash on > > 6084b576dca2e898f5c101baef151f7bfdbb606d > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > > compiler: gcc (GCC) 7.1.1 20170620 > > .config is attached > > Raw console output is attached. > > C reproducer is attached > > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > > for information about syzkaller reproducers > > Unfortunately I cannot reproduce that issue. > > > BUG: unable to handle kernel NULL pointer dereference at (null) > > IP: irqd_has_set kernel/irq/internals.h:230 [inline] > > IP: irq_may_run+0x19/0x70 kernel/irq/chip.c:506 > > PGD 0 P4D 0 > > Oops: [#1] SMP > > Dumping ftrace buffer: > > (ftrace buffer empty) > > Modules linked in: > > CPU: 0 PID: 3177 Comm: kworker/u4:2 Not tainted 4.15.0-rc3-next-20171214+ > > #67 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google > > 01/01/2011 > > RIP: 0010:irqd_has_set kernel/irq/internals.h:230 [inline] > > So this dereferences > >irq_desc->irq_data->common > > which is NULL: > > 2b:* f7 00 00 00 0c 00 testl $0xc,(%rax) <-- trapping > instruction > > > RIP: 0010:irq_may_run+0x19/0x70 kernel/irq/chip.c:506 > > RSP: 0018:88021fc03f58 EFLAGS: 00010006 > > RAX: RBX: 8802151fa400 RCX: 81243385 > > > > > RDX: 0001 RSI: RDI: 8802151fa400 > > RBP: 88021fc03f68 R08: 0001 R09: 000c > > R10: 88021fc03ee8 R11: 000c R12: 0001 > > R13: 8802151fa400 R14: 0027 R15: > > FS: () GS:88021fc0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: CR3: 0301e003 CR4: 001606f0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > > > handle_edge_irq+0x33/0x220 kernel/irq/chip.c:755 > > generic_handle_irq_desc include/linux/irqdesc.h:159 [inline] > > handle_irq+0x15/0x20 arch/x86/kernel/irq_64.c:77 > > do_IRQ+0x53/0x100 arch/x86/kernel/irq.c:229 > > common_interrupt+0xa9/0xa9 arch/x86/entry/entry_64.S:695 > > Now what confuses me is the fact that > >irq_desc->irq_data->common > > is initialized in desc_set_defaults() when the irq descriptor is > allocated. It's not written to after that. Plus it got dereferenced before. > So this looks like a stray pointer. > > I have no clue how that could be related to the reproducer. Is this > reproducing 100% on your end? If yes I surely can try to add some debug > which might help to catch this. > > Thanks, > This is yet another one where the reproducer is using AF_ALG and binding to an algorithm using 'pcrypt', so it's running into the pcrypt_free() bug which is causing slab cache corruption: https://groups.google.com/forum/#!topic/syzkaller-bugs/NKn_ivoPOpk https://patchwork.kernel.org/patch/10126761/ So let's mark it as a duplicate: #syz dup: KASAN: use-after-free Read in __list_del_entry_valid (2) Eric
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Sat, 23 Dec 2017, vcap...@pengaru.com wrote:
> On Fri, Dec 22, 2017 at 09:37:01PM -0800, vcap...@pengaru.com wrote:
> Added the following instrumentation:
>
> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> index 93edc2236282..7034eda4d494 100644
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -228,6 +228,9 @@ static int __assign_irq_vector(int irq, struct
> apic_chip_data *d,
> cpumask_and(vector_searchmask, vector_searchmask, mask);
> BUG_ON(apic->cpu_mask_to_apicid(vector_searchmask, irqdata,
> &d->cfg.dest_apicid));
> +
> + printk("allocated vector=%i maskfirst=%i\n", d->cfg.vector,
> cpumask_first(vector_searchmask));
> +
> return 0;
> }
>
> This is what I see:
>
> Upon playing song in cmus (on AC power since boot):
> Dec 22 22:26:52 iridesce kernel: allocated vector=35 maskfirst=1
>
> Yank AC:
> Dec 22 22:27:14 iridesce kernel: allocated vector=51 maskfirst=1
> Dec 22 22:27:15 iridesce kernel: do_IRQ: 0.35 No irq handler for vector
>
> So CPU 0 vector 35 got an interrupt when maskfirst=1 for 35 as seen in
> the added printk.
>
> It seems like the affinity changes are assuming a strict adherence to
> the CPU mask when the underlying hardware is treating it more as a hint.
> Perhaps handlers still need to be maintained on all CPUs in a given apic
> domain, regardless of what the masks are configured as, to cover these
> situations.
That's odd. I'll have a look after the holidays.
Merry Christmas!
Thanks,
tglx
[PATCH] pinctrl: palmas: Delete an error message for a failed memory allocation in palmas_pinctrl_probe()
From: Markus Elfring
Date: Sat, 23 Dec 2017 21:16:42 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/pinctrl/pinctrl-palmas.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-palmas.c b/drivers/pinctrl/pinctrl-palmas.c
index 4d6a5015b927..d42f18cb1bc7 100644
--- a/drivers/pinctrl/pinctrl-palmas.c
+++ b/drivers/pinctrl/pinctrl-palmas.c
@@ -1012,10 +1012,8 @@ static int palmas_pinctrl_probe(struct platform_device
*pdev)
}
pci = devm_kzalloc(&pdev->dev, sizeof(*pci), GFP_KERNEL);
- if (!pci) {
- dev_err(&pdev->dev, "Malloc for pci failed\n");
+ if (!pci)
return -ENOMEM;
- }
pci->dev = &pdev->dev;
pci->palmas = dev_get_drvdata(pdev->dev.parent);
--
2.15.1
Re: INFO: task hung in aead_recvmsg
[+Cc Steffen Klassert ]
On Tue, Dec 12, 2017 at 05:46:46PM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Sun, Dec 10, 2017 at 2:34 PM, syzbot
>
> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > ad4dac17f9d563b9e34aab78a34293b10993e9b5
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> >
> > Unfortunately, I don't have any reproducer for this bug yet.
> >
> >
> > Use struct sctp_assoc_value instead
> > INFO: task syz-executor6:7377 blocked for more than 120 seconds.
> > Not tainted 4.15.0-rc2-next-20171208+ #63
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > syz-executor6 D24416 7377 3393 0x0004
> > Call Trace:
> > context_switch kernel/sched/core.c:2800 [inline]
> > __schedule+0x8eb/0x2060 kernel/sched/core.c:3376
> > schedule+0xf5/0x430 kernel/sched/core.c:3435
> > schedule_timeout+0x43a/0x560 kernel/time/timer.c:1776
> > do_wait_for_common kernel/sched/completion.c:91 [inline]
> > __wait_for_common kernel/sched/completion.c:112 [inline]
> > wait_for_common kernel/sched/completion.c:123 [inline]
> > wait_for_completion+0x44b/0x7b0 kernel/sched/completion.c:144
> > crypto_wait_req include/linux/crypto.h:496 [inline]
> > _aead_recvmsg crypto/algif_aead.c:308 [inline]
> > aead_recvmsg+0x1396/0x1bc0 crypto/algif_aead.c:329
> > aead_recvmsg_nokey+0x60/0x80 crypto/algif_aead.c:447
> > sock_recvmsg_nosec net/socket.c:809 [inline]
> > sock_recvmsg+0xc9/0x110 net/socket.c:816
> > ___sys_recvmsg+0x29b/0x630 net/socket.c:2185
> > __sys_recvmsg+0xe2/0x210 net/socket.c:2230
> > SYSC_recvmsg net/socket.c:2242 [inline]
> > SyS_recvmsg+0x2d/0x50 net/socket.c:2237
> > entry_SYSCALL_64_fastpath+0x1f/0x96
> > RIP: 0033:0x452a39
> > RSP: 002b:7f9dc7c93c58 EFLAGS: 0212 ORIG_RAX: 002f
> > RAX: ffda RBX: 7f9dc7c94700 RCX: 00452a39
> > RDX: RSI: 20539fc8 RDI: 0025
> > RBP: R08: R09:
> > R10: R11: 0212 R12:
> > R13: 00a6f7ff R14: 7f9dc7c949c0 R15:
> >
> > Showing all locks held in the system:
> > 2 locks held by khungtaskd/671:
> > #0: (rcu_read_lock){}, at: []
> > check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
> > #0: (rcu_read_lock){}, at: [] watchdog+0x1c5/0xd60
> > kernel/hung_task.c:249
> > #1: (tasklist_lock){.+.+}, at: []
> > debug_show_all_locks+0xd3/0x400 kernel/locking/lockdep.c:4554
> > 1 lock held by rsyslogd/2995:
> > #0: (&f->f_pos_lock){+.+.}, at: [<34bb33fc>]
> > __fdget_pos+0x131/0x1a0 fs/file.c:765
> > 2 locks held by getty/3116:
> > #0: (&tty->ldisc_sem){}, at: [<8df66e53>]
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<870ebf25>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3117:
> > #0: (&tty->ldisc_sem){}, at: [<8df66e53>]
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<870ebf25>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3118:
> > #0: (&tty->ldisc_sem){}, at: [<8df66e53>]
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<870ebf25>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3119:
> > #0: (&tty->ldisc_sem){}, at: [<8df66e53>]
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<870ebf25>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3120:
> > #0: (&tty->ldisc_sem){}, at: [<8df66e53>]
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<870ebf25>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3121:
> > #0: (&tty->ldisc_sem){}, at: [<8df66e53>]
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<870ebf25>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3122:
> > #0: (&tty->ldisc_sem){}, at: [<8df66e53>]
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<870ebf25>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 1 lock held by syz-executor6/7377:
> > #0: (sk_lock-AF_ALG){+.+.}, at: [<96d0e030>] lock_sock
> > include/net/sock.h:1463 [inline]
> > #0: (sk_lock-AF_ALG){+.+.}, at: [<96d0e030>]
> > aead_recvmsg+0xb3/0x1bc0
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Fri, Dec 22, 2017 at 09:37:01PM -0800, vcap...@pengaru.com wrote:
> On Wed, Dec 20, 2017 at 01:33:45AM +0100, Thomas Gleixner wrote:
> > On Tue, 19 Dec 2017, vcap...@pengaru.com wrote:
> > > On Wed, Dec 20, 2017 at 12:22:12AM +0100, Pavel Machek wrote:
> > > > You forgot to mention commit id :-).
> > > >
> > >
> > > That is very strange, anyhow:
> > >
> > > commit fdba46ffb4c203b6e6794163493fd310f98bb4be
> > > Author: Thomas Gleixner
> > > Date: Wed Sep 13 23:29:27 2017 +0200
> > >
> > > x86/apic: Get rid of multi CPU affinity
> > >
> > >
> > > Will try reverting soon, just a bit busy today out in the desert and the
> > > sun
> > > is going down so my solar panel is useless.
> >
> > The revert is not trivial.
> >
> > What is the exact problem and how do you reproduce that?
> >
> > Thanks,
> >
>
> So I had some time today to poke at this some more. Since it looks to
> be easily reproduced by simply pulling the AC power while playing music
> or doing IO, and dmesg clearly reports using mwait, I tried booting with
> idle=nomwait to see if that made any difference. It didn't, the same
> thing still occurs.
>
> In trying to make sense of this totally unfamiliar apic code and better
> understand these changes, I came across this comment which seemed a bit
> telling:
>
> 40 void flat_vector_allocation_domain(int cpu, struct cpumask *retmask,
> 41const struct cpumask *mask)
> 42 {
> 43 /*
> 44 * Careful. Some cpus do not strictly honor the set of cpus
> 45 * specified in the interrupt destination when using lowest
> 46 * priority interrupt delivery mode.
> 47 *
> 48 * In particular there was a hyperthreading cpu observed to
> 49 * deliver interrupts to the wrong hyperthread when only one
> 50 * hyperthread was specified in the interrupt desitination.
> 51 */
> 52 cpumask_clear(retmask);
> 53 cpumask_bits(retmask)[0] = APIC_ALL_CPUS;
> 54 }
>
> It's this allocation domain mask hook which has been bypassed by the
> offending commit. The existing approach is more robust in the face of
> relaxed adherence to destination cpumasks since it's all-inclusive,
> whereas the new code is exclusive to a specific cpu.
>
> Is it possible what I'm observing is just another manifestation of
> what's being described in that comment? This is a core 2 duo, so not
> hyper-threaded. But maybe something funny happens when switching
> cstates in response to interrupts - like maybe the wrong cpu can be used
> if it can save power vs. powering up another? Just thinking out loud
> here.
>
> In any case, 4.15-rc4 is quite unusable on my machine because of this.
>
Some more food for thought:
Added the following instrumentation:
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 93edc2236282..7034eda4d494 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -228,6 +228,9 @@ static int __assign_irq_vector(int irq, struct
apic_chip_data *d,
cpumask_and(vector_searchmask, vector_searchmask, mask);
BUG_ON(apic->cpu_mask_to_apicid(vector_searchmask, irqdata,
&d->cfg.dest_apicid));
+
+ printk("allocated vector=%i maskfirst=%i\n", d->cfg.vector,
cpumask_first(vector_searchmask));
+
return 0;
}
This is what I see:
Upon playing song in cmus (on AC power since boot):
Dec 22 22:26:52 iridesce kernel: allocated vector=35 maskfirst=1
Yank AC:
Dec 22 22:27:14 iridesce kernel: allocated vector=51 maskfirst=1
Dec 22 22:27:15 iridesce kernel: do_IRQ: 0.35 No irq handler for vector
So CPU 0 vector 35 got an interrupt when maskfirst=1 for 35 as seen in
the added printk.
It seems like the affinity changes are assuming a strict adherence to
the CPU mask when the underlying hardware is treating it more as a hint.
Perhaps handlers still need to be maintained on all CPUs in a given apic
domain, regardless of what the masks are configured as, to cover these
situations.
Regards,
Vito Caputo
[GIT PULL] libnvdimm fixes for 4.15-rc5
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
...to receive:
* NVDIMM namespaces, configured to enforce 1GB alignment, fail to
initialize on platforms that mis-align the start or end of the physical
address range.
* The Linux implementation of the BTT (Block Translation Table) is
incompatible with the UEFI 2.7 definition of the BTT format. The BTT
layers a software atomic sector semantic on top of an NVDIMM namespace.
Linux needs to be compatible with the UEFI definition to enable boot
support or any pre-OS access of data on a BTT enabled namespace.
* A fix for ACPI SMART notification events, this allows a userspace
monitor to register for health events rather than poll. This has been
broken since it was initially merged as the unit test inadvertently
worked around the problem. The urgency for fixing this during the -rc
series is driven by how expensive it is to poll for this data (System
Management Mode entry).
These fixes are all tagged for -stable and have received a build
success notification from the kbuild robot. Full changelogs below:
---
The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:
Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
for you to fetch changes up to 24e3a7fb60a9187e5df90e5fa655ffc94b9c4f77:
libnvdimm, btt: Fix an incompatibility in the log layout (2017-12-21 14:59:27
-0800)
Dan Williams (3):
acpi, nfit: fix health event notification
libnvdimm, pfn: fix start_pad handling for aligned namespaces
libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment
Vishal Verma (2):
libnvdimm, btt: add a couple of missing kernel-doc lines
libnvdimm, btt: Fix an incompatibility in the log layout
drivers/acpi/nfit/core.c | 9 ++-
drivers/nvdimm/btt.c | 201 ++
drivers/nvdimm/btt.h | 47 ++-
drivers/nvdimm/pfn_devs.c | 20 +++--
4 files changed, 236 insertions(+), 41 deletions(-)
commit adf6895754e2503d994a765535fd1813f8834674
Author: Dan Williams
Date: Thu Nov 30 19:42:52 2017 -0800
acpi, nfit: fix health event notification
Integration testing with a BIOS that generates injected health event
notifications fails to communicate those events to userspace. The nfit
driver neglects to link the ACPI DIMM device with the necessary driver
data so acpi_nvdimm_notify() fails this lookup:
nfit_mem = dev_get_drvdata(dev);
if (nfit_mem && nfit_mem->flags_attr)
sysfs_notify_dirent(nfit_mem->flags_attr);
Add the necessary linkage when installing the notification handler and
clean it up when the nfit driver instance is torn down.
Cc:
Cc: Toshi Kani
Cc: Vishal Verma
Fixes: ba9c8dd3c222 ("acpi, nfit: add dimm device notification support")
Reported-by: Daniel Osawa
Tested-by: Daniel Osawa
Signed-off-by: Dan Williams
commit 19deaa217bc04e83b59b5e8c8229eb0e53ad9efc
Author: Dan Williams
Date: Tue Dec 19 15:07:10 2017 -0800
libnvdimm, pfn: fix start_pad handling for aligned namespaces
The alignment checks at pfn driver startup fail to properly account for
the 'start_pad' in the case where the namespace is misaligned relative
to its internal alignment. This is typically triggered in 1G aligned
namespace, but could theoretically trigger with small namespace
alignments. When this triggers the kernel reports messages of the form:
dax2.1: bad offset: 0x3c00 dax disabled align: 0x4000
Cc:
Fixes: 1ee6667cd8d1 ("libnvdimm, pfn, dax: fix initialization vs
autodetect...")
Reported-by: Jane Chu
Signed-off-by: Dan Williams
commit 41fce90f26333c4fa82e8e43b9ace86c4e8a0120
Author: Dan Williams
Date: Mon Dec 4 14:07:43 2017 -0800
libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment
The following namespace configuration attempt:
# ndctl create-namespace -e namespace0.0 -m devdax -a 1G -f
libndctl: ndctl_dax_enable: dax0.1: failed to enable
Error: namespace0.0: failed to enable
failed to reconfigure namespace: No such device or address
...fails when the backing memory range is not physically aligned to 1G:
# cat /proc/iomem | grep Persistent
21000-30fff : Persistent Memory (legacy)
In the above example the 4G persistent memory range starts and ends on a
256MB boundary.
We handle this case correctly when needing to handle cases that violate
section alignment (128MB) collisions against "System RAM", and we simply
need to extend that padding/truncation for the 1GB alignment use case.
Cc:
Fixes
Re: INFO: task hung in lock_sock_nested
On Tue, Dec 12, 2017 at 05:47:34PM +0100, Dmitry Vyukov wrote:
> On Sun, Dec 10, 2017 at 2:37 PM, syzbot
>
> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 51e18a453f5f59a40c721d4aeab082b4e2e9fac6
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> >
> > Unfortunately, I don't have any reproducer for this bug yet.
> >
> >
> > RDS: rds_bind could not find a transport for 172.20.1.187, load rds_tcp or
> > rds_rdma?
> > INFO: task syz-executor2:19495 blocked for more than 120 seconds.
> > Not tainted 4.15.0-rc2+ #148
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > syz-executor2 D25200 19495 3406 0x0004
> > Call Trace:
> > context_switch kernel/sched/core.c:2799 [inline]
> > __schedule+0x8eb/0x2060 kernel/sched/core.c:3375
> > schedule+0xf5/0x430 kernel/sched/core.c:3434
> > __lock_sock+0x1dc/0x2f0 net/core/sock.c:2240
> > lock_sock_nested+0xf3/0x110 net/core/sock.c:2764
> > lock_sock include/net/sock.h:1461 [inline]
> > af_alg_sendmsg+0x349/0x1080 crypto/af_alg.c:858
> > aead_sendmsg+0x103/0x150 crypto/algif_aead.c:76
> > sock_sendmsg_nosec net/socket.c:636 [inline]
> > sock_sendmsg+0xca/0x110 net/socket.c:646
> > ___sys_sendmsg+0x75b/0x8a0 net/socket.c:2026
> > __sys_sendmsg+0xe5/0x210 net/socket.c:2060
> > SYSC_sendmsg net/socket.c:2071 [inline]
> > SyS_sendmsg+0x2d/0x50 net/socket.c:2067
> > entry_SYSCALL_64_fastpath+0x1f/0x96
> > RIP: 0033:0x452a39
> > RSP: 002b:7f63f58cfc58 EFLAGS: 0212 ORIG_RAX: 002e
> > RAX: ffda RBX: 00758020 RCX: 00452a39
> > RDX: 0040 RSI: 2063 RDI: 0015
> > RBP: 0001 R08: R09:
> > R10: R11: 0212 R12: 006ee0b8
> > R13: R14: 7f63f58d06d4 R15:
> >
> > Showing all locks held in the system:
> > 2 locks held by khungtaskd/663:
> > #0: (rcu_read_lock){}, at: []
> > check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
> > #0: (rcu_read_lock){}, at: [] watchdog+0x1c5/0xd60
> > kernel/hung_task.c:249
> > #1: (tasklist_lock){.+.+}, at: []
> > debug_show_all_locks+0xd3/0x400 kernel/locking/lockdep.c:4554
> > 1 lock held by rsyslogd/3008:
> > #0: (&f->f_pos_lock){+.+.}, at: []
> > __fdget_pos+0x131/0x1a0 fs/file.c:770
> > 2 locks held by getty/3130:
> > #0: (&tty->ldisc_sem){}, at: []
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<2bd4e259>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3131:
> > #0: (&tty->ldisc_sem){}, at: []
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<2bd4e259>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3132:
> > #0: (&tty->ldisc_sem){}, at: []
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<2bd4e259>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3133:
> > #0: (&tty->ldisc_sem){}, at: []
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<2bd4e259>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3134:
> > #0: (&tty->ldisc_sem){}, at: []
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<2bd4e259>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3135:
> > #0: (&tty->ldisc_sem){}, at: []
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<2bd4e259>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 2 locks held by getty/3136:
> > #0: (&tty->ldisc_sem){}, at: []
> > ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
> > #1: (&ldata->atomic_read_lock){+.+.}, at: [<2bd4e259>]
> > n_tty_read+0x2f2/0x1a10 drivers/tty/n_tty.c:2131
> > 1 lock held by syz-executor2/19506:
> > #0: (sk_lock-AF_ALG){+.+.}, at: [] lock_sock
> > include/net/sock.h:1461 [inline]
> > #0: (sk_lock-AF_ALG){+.+.}, at: []
> > aead_recvmsg+0xb3/0x1bc0 crypto/algif_aead.c:327
> >
I think this is a duplicate:
#syz dup: INFO: task hung in aead_recvmsg
There is a thread hung in aead_recvmsg() while holding the socket lock, so it's
blocking other threads too.
Eric
Re: [GIT pull] x86/pti: Preparatory changes
On Sat, Dec 23, 2017 at 11:23 AM, Thomas Gleixner wrote: > > Todays Advent calendar window contains twentyfour easy to digest > patches. Thanks, this was nice and clear and I saw nothing odd at all. My only reaction ended up being that I don't much like how complex the NR_CPUS config entry has become, and how confusing that is. For example, we now have range 2 64 if SMP && X86_32 && X86_BIGSMP but then we have default "8192" if MAXSMP which seems to make no sense, and unlike some of the other defaults it's not clear that those things aren't compatible. It turns out that MAXSMP is limited to X86_64, but that's not at all obvious within that config entry. So I think that could be simplified by introducing separate MAX_CONFIG_CPUS etc entries (that aren't user choice, but just codify the limits), so that there would be some more abstraction there. So the NR_CPUS thing would become something like config NR_CPUS int "Maximum number of CPUs" if SMP && !MAXSMP range MIN_CONFIG_CPUS MAX_CONFIG_CPUS default DEF_CONFIG_CPUS and then have separate (simpler) config expressions for those MIN/MAX/DEF values, rather than making it one big complex config entry. But that was not new complexity (just added complexity to an already confusing case), and it's purely bike-shedding. So I've pulled this stuff, and will push out once it passes my trivial build test (which I obviously expect it to do, since my final build test is much more limited than what you guys do). Linus
Re: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop
On Sat, Dec 23, 2017 at 02:32:52PM +0100, Thomas Gleixner wrote: > On Sat, 23 Dec 2017, Dexuan Cui wrote: > > > > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com] > > > Sent: Friday, December 22, 2017 14:29 > > > > > > The output of that precise command run just now on a freshly-compiled > > > copy of that commit is attached. > > > > > > On Fri, Dec 22, 2017 at 09:31:28PM +, Dexuan Cui wrote: > > > > > From: Alexandru Chirvasitu [mailto:achirva...@gmail.com] > > > > > Sent: Friday, December 22, 2017 06:21 > > > > > > > > > > In the absence of logs, the best I can do at the moment is attach a > > > > > picture of the screen I am presented with on the apic=debug boot > > > > > attempt. > > > > > Alex > > > > > > > > The panic happens in irq_matrix_assign_system+0x4e/0xd0 in your picture. > > > > IMO we should find which line of code causes the panic. I suppose > > > > "objdump -D kernel/irq/matrix.o" can help to do that. > > > > > > > > Thanks, > > > > -- Dexuan > > > > The BUG_ON panic happens at line 147: > >BUG_ON(!test_and_clear_bit(bit, cm->alloc_map)); > > > > I'm sure Thomas and Dou know it better than me. > > I'll have a look after the holidays. > Thanks for that! A quick follow-up on my inability to make kexec / kdump work in order to perhaps produce better logs: I've done another bisect for that with this result: # first bad commit: [e802a51ede91350438c051da2f238f5e8c918ead] x86/idt: Consolidate IDT invalidation I am quite certain this is the one for that issue. Its only parent is # good: [8f55868f9e42fea56021b17421914b9e4fda4960] x86/idt: Remove unused set_trap_gate() (i.e. one of the "good" commits I hit upon during the bisect). On the core 2 duo machine I've been referring to e802a51 and later commits simply return me to a regular BIOS boot when issuing either kexec -e on a loaded crash kernel or crashing with echo c > /proc/sysrq-trigger. Alex
[PATCH] pinctrl: at91: Delete an error message for a failed memory allocation in at91_pinctrl_mux_mask()
From: Markus Elfring
Date: Sat, 23 Dec 2017 20:44:27 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/pinctrl/pinctrl-at91.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 03492e3c09fa..297f1d161211 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1050,10 +1050,8 @@ static int at91_pinctrl_mux_mask(struct at91_pinctrl
*info,
info->nmux = size / gpio_banks;
info->mux_mask = devm_kzalloc(info->dev, sizeof(u32) * size,
GFP_KERNEL);
- if (!info->mux_mask) {
- dev_err(info->dev, "could not alloc mux_mask\n");
+ if (!info->mux_mask)
return -ENOMEM;
- }
ret = of_property_read_u32_array(np, "atmel,mux-mask",
info->mux_mask, size);
--
2.15.1
Re: WARNING in rcu_process_callbacks
On Sat, 23 Dec 2017, syzbot wrote: > Hello, > > syzkaller hit the following crash on 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > > Unfortunately, I don't have any reproducer for this bug yet. > > > RBP: 7f50826f4a90 R08: R09: > R10: R11: 0212 R12: 004b75bb > R13: 7f50826f4bc8 R14: 004b75bb R15: > WARNING: CPU: 0 PID: 7719 at kernel/rcu/tree.c:2714 arch_local_irq_disable > arch/x86/include/asm/paravirt.h:772 [inline] So the only thing which triggers a BUG in that code is the paravirt stuff #define PVOP_TEST_NULL(op) BUG_ON(op == NULL) Your config has PARAVIRT_DEBUG=y So this is again something which got executed before a gazillion of times and then something becomes NULL. In this case it's pv_irq_ops.irq_disable I've seen such unexplainable NULL pointers in quite some sysbot bug reports lately. The irq_desc->irq_data.common issue is more or less the same problem. This really stinks like a stray pointer. Thanks, tglx
[GIT pull] x86/pti: Preparatory changes
Linus, please pull the latest x86-pti-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pti-for-linus Todays Advent calendar window contains twentyfour easy to digest patches. The original plan was to have twenty three matching the date, but a late fixup made that moot. - Move the cpu_entry_area mapping out of the fixmap into a separate address space. That's necessary because the fixmap becomes too big with NRCPUS=8192 and this caused already subtle and hard to diagnose failures. The top most patch is fresh from today and cures a brain slip of that tall grumpy german greybeard, who ignored the intricacies of 32bit wraparounds. - Limit the number of CPUs on 32bit to 64. That's insane big already, but at least it's small enough to prevent address space issues with the cpu_entry_area map, which have been observed and debugged with the fixmap code - A few TLB flush fixes in various places plus documentation which of the TLB functions should be used for what. - Rename the SYSENTER stack to CPU_ENTRY_AREA stack as it is used for more than sysenter now and keeping the name makes backtraces confusing. - Prevent LDT inheritance on exec() by moving it to arch_dup_mmap(), which is only invoked on fork(). - Make vysycall more robust. - A few fixes and cleanups of the debug_pagetables code. Check PAGE_PRESENT instead of checking the PTE for 0 and a cleanup of the C89 initialization of the address hint array which already was out of sync with the index enums. - Move the ESPFIX init to a different place to prepare for PTI. - Several code moves with no functional change to make PTI integration simpler and header files less convoluted. - Documentation fixes and clarifications. Thanks, tglx --> Andy Lutomirski (3): x86/vsyscall/64: Explicitly set _PAGE_USER in the pagetable hierarchy x86/vsyscall/64: Warn and fail vsyscall emulation in NATIVE mode x86/mm/64: Improve the memory map documentation Dave Hansen (4): x86/entry: Rename SYSENTER_stack to CPU_ENTRY_AREA_entry_stack x86/mm: Move the CR3 construction functions to tlbflush.h x86/mm: Remove hard-coded ASID limit checks x86/mm: Put MMU to hardware ASID translation in one place Peter Zijlstra (8): x86/ldt: Rework locking x86/doc: Remove obvious weirdnesses from the x86 MM layout documentation x86/uv: Use the right TLB-flush API x86/microcode: Dont abuse the TLB-flush interface x86/mm: Use __flush_tlb_one() for kernel memory x86/mm: Remove superfluous barriers x86/mm: Add comments to clarify which TLB-flush functions are supposed to flush what x86/mm: Create asm/invpcid.h Thomas Gleixner (9): x86/Kconfig: Limit NR_CPUS on 32-bit to a sane amount x86/mm/dump_pagetables: Check PAGE_PRESENT for real x86/mm/dump_pagetables: Make the address hints correct and readable arch, mm: Allow arch_dup_mmap() to fail x86/ldt: Prevent LDT inheritance on exec x86/cpu_entry_area: Move it to a separate unit x86/cpu_entry_area: Move it out of the fixmap init: Invoke init_espfix_bsp() from mm_init() x86/cpu_entry_area: Prevent wraparound in setup_cpu_entry_area_ptes() on 32bit Documentation/x86/x86_64/mm.txt | 24 +++--- arch/powerpc/include/asm/mmu_context.h | 5 +- arch/um/include/asm/mmu_context.h| 3 +- arch/unicore32/include/asm/mmu_context.h | 5 +- arch/x86/Kconfig | 3 +- arch/x86/entry/entry_32.S| 12 +-- arch/x86/entry/entry_64.S| 4 +- arch/x86/entry/vsyscall/vsyscall_64.c| 38 - arch/x86/include/asm/cpu_entry_area.h| 68 +++ arch/x86/include/asm/desc.h | 1 + arch/x86/include/asm/espfix.h| 7 +- arch/x86/include/asm/fixmap.h| 71 +--- arch/x86/include/asm/invpcid.h | 53 arch/x86/include/asm/mmu.h | 4 +- arch/x86/include/asm/mmu_context.h | 54 arch/x86/include/asm/pgtable_32_types.h | 15 +++- arch/x86/include/asm/pgtable_64_types.h | 47 ++- arch/x86/include/asm/processor.h | 6 +- arch/x86/include/asm/stacktrace.h| 4 +- arch/x86/include/asm/tlbflush.h | 136 -- arch/x86/kernel/asm-offsets.c| 4 +- arch/x86/kernel/asm-offsets_32.c | 2 +- arch/x86/kernel/cpu/common.c | 100 +- arch/x86/kernel/cpu/microcode/intel.c| 13 --- arch/x86/kernel/dumpstack.c | 11 +-- arch/x86/kernel/dumpstack_32.c | 6 +- arch/x86/kernel/dumpstack_64.c | 12 ++- arch/x86/kernel/ldt.c| 47 ++- arch/x86/kernel/smpboot.c| 6 +- arch/x86/kernel/traps.c
[PATCH v2] mtd: nand: vf610: fix error handling in vf610_nfc_probe()
vf610_nfc_probe() misses error handling of mtd_device_register().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
v2: Add nand_cleanup() to undone nand_scan_tail() as Boris Brezillon noted.
drivers/mtd/nand/vf610_nfc.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 8037d4b48a05..2dac25a8ccbf 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -682,7 +682,7 @@ static int vf610_nfc_probe(struct platform_device *pdev)
dev_err(nfc->dev,
"Only one NAND chip supported!\n");
err = -EINVAL;
- goto error;
+ goto err_node;
}
nand_set_flash_node(chip, child);
@@ -712,7 +712,7 @@ static int vf610_nfc_probe(struct platform_device *pdev)
err = devm_request_irq(nfc->dev, irq, vf610_nfc_irq, 0, DRV_NAME, mtd);
if (err) {
dev_err(nfc->dev, "Error requesting IRQ!\n");
- goto error;
+ goto err_node;
}
vf610_nfc_preinit_controller(nfc);
@@ -720,7 +720,7 @@ static int vf610_nfc_probe(struct platform_device *pdev)
/* first scan to find the device and get the page size */
err = nand_scan_ident(mtd, 1, NULL);
if (err)
- goto error;
+ goto err_node;
vf610_nfc_init_controller(nfc);
@@ -732,20 +732,20 @@ static int vf610_nfc_probe(struct platform_device *pdev)
if (mtd->writesize + mtd->oobsize > PAGE_2K + OOB_MAX - 8) {
dev_err(nfc->dev, "Unsupported flash page size\n");
err = -ENXIO;
- goto error;
+ goto err_node;
}
if (chip->ecc.mode == NAND_ECC_HW) {
if (mtd->writesize != PAGE_2K && mtd->oobsize < 64) {
dev_err(nfc->dev, "Unsupported flash with hwecc\n");
err = -ENXIO;
- goto error;
+ goto err_node;
}
if (chip->ecc.size != mtd->writesize) {
dev_err(nfc->dev, "Step size needs to be page size\n");
err = -ENXIO;
- goto error;
+ goto err_node;
}
/* Only 64 byte ECC layouts known */
@@ -765,7 +765,7 @@ static int vf610_nfc_probe(struct platform_device *pdev)
} else {
dev_err(nfc->dev, "Unsupported ECC strength\n");
err = -ENXIO;
- goto error;
+ goto err_node;
}
chip->ecc.read_page = vf610_nfc_read_page;
@@ -777,14 +777,19 @@ static int vf610_nfc_probe(struct platform_device *pdev)
/* second phase scan */
err = nand_scan_tail(mtd);
if (err)
- goto error;
+ goto err_node;
platform_set_drvdata(pdev, mtd);
/* Register device in MTD */
- return mtd_device_register(mtd, NULL, 0);
+ err = mtd_device_register(mtd, NULL, 0);
+ if (err)
+ goto err_nand;
+ return 0;
-error:
+err_nand:
+ nand_cleanup(chip);
+err_node:
of_node_put(nand_get_flash_node(chip));
err_clk:
clk_disable_unprepare(nfc->clk);
--
2.7.4
Re: [PATCH] drm: fix tainted kernel caused by drm_panel_orientation_quirks.c
Hi,
On 21-12-17 19:46, David Lechner wrote:
drm_panel_orientation_quirks.c introduced in commit 404d1a3edc38 ("drm:
Add panel orientation quirks, v6.") taints the kernel when compiled as a
module. Fix this by adding MODULE_LICENSE().
Signed-off-by: David Lechner
Thank you, I've pushed this patch to drm-misc-next.
Regards,
Hans
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 901a4e9..1f2af70 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#ifdef CONFIG_DMI
@@ -172,3 +173,5 @@ int drm_get_panel_orientation_quirk(int width, int height)
EXPORT_SYMBOL(drm_get_panel_orientation_quirk);
#endif
+
+MODULE_LICENSE("Dual MIT/GPL");
[tip:WIP.x86/pti 1/1] arch/x86/mm/cpu_entry_area.c:153:33: error: 'CPU_ENTRY_AREA_END' undeclared; did you mean 'CPU_ENTRY_AREA_BASE'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/pti
head: 1c4c1c2fa0c5c121210d47bc74ee85c5032b3ea9
commit: 1c4c1c2fa0c5c121210d47bc74ee85c5032b3ea9 [1/1] x86/pti: Prevent
wraparound in setup_cpu_entry_area_ptes() on 32bit
config: i386-randconfig-x007-201752 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 1c4c1c2fa0c5c121210d47bc74ee85c5032b3ea9
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
arch/x86/mm/cpu_entry_area.c: In function 'setup_cpu_entry_area_ptes':
>> arch/x86/mm/cpu_entry_area.c:153:33: error: 'CPU_ENTRY_AREA_END' undeclared
>> (first use in this function); did you mean 'CPU_ENTRY_AREA_BASE'?
for (; start < end && start >= CPU_ENTRY_AREA_END; start += PMD_SIZE)
^~
CPU_ENTRY_AREA_BASE
arch/x86/mm/cpu_entry_area.c:153:33: note: each undeclared identifier is
reported only once for each function it appears in
vim +153 arch/x86/mm/cpu_entry_area.c
140
141 static __init void setup_cpu_entry_area_ptes(void)
142 {
143 #ifdef CONFIG_X86_32
144 unsigned long start, end;
145
146 BUILD_BUG_ON(CPU_ENTRY_AREA_PAGES * PAGE_SIZE <
CPU_ENTRY_AREA_MAP_SIZE);
147 BUG_ON(CPU_ENTRY_AREA_BASE & ~PMD_MASK);
148
149 start = CPU_ENTRY_AREA_BASE;
150 end = start + CPU_ENTRY_AREA_MAP_SIZE;
151
152 /* Careful here: start + PMD_SIZE might wrap around */
> 153 for (; start < end && start >= CPU_ENTRY_AREA_END; start +=
> PMD_SIZE)
154 populate_extra_pte(start);
155 #endif
156 }
157
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: 92a0f81d89 ("x86/cpu_entry_area: Move it out of the fixmap"): BUG: kernel hang in boot stage
On Sun, 24 Dec 2017, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/pti > > commit 92a0f81d89571e3e8759366e050ee05cc545ef99 > Author: Thomas Gleixner > AuthorDate: Wed Dec 20 18:51:31 2017 +0100 > Commit: Ingo Molnar > CommitDate: Fri Dec 22 20:13:05 2017 +0100 > > x86/cpu_entry_area: Move it out of the fixmap Yes, I'm an idiot. for (; start < end; start += PMD_SIZE) which works fine when start + PMD_SIZE does not wrap around to 0 Fix is on the way to git. Thanks, tglx
92a0f81d89 ("x86/cpu_entry_area: Move it out of the fixmap"): BUG: kernel hang in boot stage
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/pti commit 92a0f81d89571e3e8759366e050ee05cc545ef99 Author: Thomas Gleixner AuthorDate: Wed Dec 20 18:51:31 2017 +0100 Commit: Ingo Molnar CommitDate: Fri Dec 22 20:13:05 2017 +0100 x86/cpu_entry_area: Move it out of the fixmap Put the cpu_entry_area into a separate P4D entry. The fixmap gets too big and 0-day already hit a case where the fixmap PTEs were cleared by cleanup_highmap(). Aside of that the fixmap API is a pain as it's all backwards. Signed-off-by: Thomas Gleixner Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Linus Torvalds Cc: Peter Zijlstra Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar ed1bbc40a0 x86/cpu_entry_area: Move it to a separate unit 92a0f81d89 x86/cpu_entry_area: Move it out of the fixmap 679d0580c1 x86/ldt: Make the LDT mapping RO 3056af3db3 Merge branch 'WIP.x86/pti.base' +---+++++ | | ed1bbc40a0 | 92a0f81d89 | 679d0580c1 | 3056af3db3 | +---+++++ | boot_successes| 77 | 0 | 0 | 0 | | boot_failures | 0 | 26 | 43 | 19 | | BUG:kernel_hang_in_boot_stage | 0 | 26 | 43 | 19 | +---+++++ [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] BRK [0x07cb7000, 0x07cb7fff] PGTABLE [0.00] BRK [0x07cb8000, 0x07cb8fff] PGTABLE [0.00] BRK [0x07cb9000, 0x07cb9fff] PGTABLE [0.00] BRK [0x07cba000, 0x07cbafff] PGTABLE BUG: kernel hang in boot stage # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start 858ee49740dd2f7e85f1b45c2af708b6c08f0771 v4.14 -- git bisect good 7fbbd5cbebf118a9e09f5453f686656a167c3d1c # 23:18 G 11 00 0 x86/entry/64: Remove the SYSENTER stack canary git bisect good 4fe2d8b11a370af286287a2661de9d4e6c9a145a # 23:27 G 11 00 0 x86/entry: Rename SYSENTER_stack to CPU_ENTRY_AREA_entry_stack git bisect good dd95f1a4b5ca904c78e6a097091eb21436478abb # 23:39 G 11 00 0 x86/mm: Put MMU to hardware ASID translation in one place git bisect bad 613e396bc0d4c7604fba23256644e78454c68cf6 # 23:47 B 0 2 16 0 init: Invoke init_espfix_bsp() from mm_init() git bisect good ed1bbc40a0d10e0c5c74fe7bdc6298295cf40255 # 23:58 G 11 00 0 x86/cpu_entry_area: Move it to a separate unit git bisect bad 92a0f81d89571e3e8759366e050ee05cc545ef99 # 00:07 B 0 11 36 11 x86/cpu_entry_area: Move it out of the fixmap # first bad commit: [92a0f81d89571e3e8759366e050ee05cc545ef99] x86/cpu_entry_area: Move it out of the fixmap git bisect good ed1bbc40a0d10e0c5c74fe7bdc6298295cf40255 # 00:19 G 31 00 0 x86/cpu_entry_area: Move it to a separate unit # extra tests on HEAD of tip/master git bisect bad 3056af3db33464f58e51ddcc9fd5552413e3a6f2 # 00:55 B 0 5 27 8 Merge branch 'WIP.x86/pti.base' # extra tests on tree/branch tip/WIP.x86/pti git bisect bad 679d0580c1655be350392a66a45cedc9f4c5e139 # 01:14 B 0 2 42 26 x86/ldt: Make the LDT mapping RO # extra tests on tree/branch tip/master git bisect bad 3056af3db33464f58e51ddcc9fd5552413e3a6f2 # 01:14 B 0 19 33 0 Merge branch 'WIP.x86/pti.base' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/lkp Intel Corporation dmesg-quantal-lkp-hsw01-11:20171224000613:i386-randconfig-a1-201751:4.14.0-00142-g92a0f81:2.gz Description: application/gzip #!/bin/bash kernel=$1 kvm=( qemu-system-x86_64 -enable-kvm -cpu kvm64 -kernel $kernel -m 512 -smp 2 -device e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -watchdog-action debug -rtc base=localtime -serial stdio -display none -monitor null ) append=( root=/dev/ram0 hung_task_panic=1 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel
Re: [PATCH 4.4 00/78] 4.4.108-stable review
On 12/23/2017 08:26 AM, Greg Kroah-Hartman wrote:
On Sat, Dec 23, 2017 at 08:13:48AM -0800, Guenter Roeck wrote:
On 12/23/2017 06:46 AM, Greg Kroah-Hartman wrote:
On Sat, Dec 23, 2017 at 10:19:32AM +0100, Greg Kroah-Hartman wrote:
On Fri, Dec 22, 2017 at 10:18:31AM -0800, Guenter Roeck wrote:
On Fri, Dec 22, 2017 at 09:45:41AM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.108 release.
There are 78 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Dec 24 08:45:30 UTC 2017.
Anything received after that time might be too late.
I lost track with versions. This is with v4.4.107-79-g0989207.
Build results:
total: 145 pass: 144 fail: 1
Failed builds:
alpha:allmodconfig
Qemu test results:
total: 118 pass: 118 fail: 0
alpha/include/asm/mmu_context.h: In function 'ev5_switch_mm':
arch/alpha/include/asm/mmu_context.h:158:2: error: implicit declaration of
function 'task_thread_info'
arch/alpha/include/asm/mmu_context.h:158:24: error: invalid type argument of
'->' (have 'int')
alpha/include/asm/mmu_context.h: In function 'init_new_context':
arch/alpha/include/asm/mmu_context.h:236:24: error: invalid type argument of
'->' (have 'int')
arch/alpha/include/asm/mmu_context.h: In function 'enter_lazy_tlb':
arch/alpha/include/asm/mmu_context.h:250:23: error: invalid type argument of
'->' (have 'int')
Didn't I already report this ?
I thought that was a 4.9 issue. Let me look into this later today,
thanks for the report...
Hm, yeah, looks to be the same issue that 4.9 had. I resolve that by
ripping out the whole series, which I don't want to do here. Let me see
if I can resolve it simpler...
Apply 8ee912dab95f ("alpha: fix build failures") and fix conflict by picking
the new include files. I am currently rebuilding with that applied to ensure
that it breaks nothing else.
Now added, and pushed out, let me know how that goes.
Confirmed fixed. I'll send a complete build report later.
Again, many thanks for your help here,
My pleasure. And pure self-interest, of course. After all, I can hardly argue
for stable release merges if stable is broken.
Thanks,
Guenter
Re: [PATCH 4.14 000/159] 4.14.9-stable review
On 12/23/2017 06:21 AM, Greg Kroah-Hartman wrote: On Fri, Dec 22, 2017 at 10:15:50AM -0800, Guenter Roeck wrote: On Fri, Dec 22, 2017 at 04:54:41PM +0100, Greg Kroah-Hartman wrote: On Fri, Dec 22, 2017 at 04:08:39PM +0100, Greg Kroah-Hartman wrote: On Fri, Dec 22, 2017 at 09:44:45AM +0100, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.9 release. There are 159 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Dec 24 08:45:36 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. Ok, that blew up hard on arm64, there's now a -rc2 out with a fix for that. Hopefully :) kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.9-rc2.gz And because it's just been one of those weeks, there's now a -rc3 out due to a bunch of important BPF patches. I'll stop now to give you all a chance to test... I can't keep up with this. I'll let my builders try again tonight and report tomorrow. This is what I have so far. h8300 builds are broken. include/linux/compiler.h:344:2: error: implicit declaration of function ‘smp_read_barrier_depends’ Seen when building arch/h8300/kernel/asm-offsets.c. sparc32 builds are broken with the same error, in this case when building init/do_mounts_initrd.c. Ok, I think I found the problem for this, and have added a fix to the tree. It builds here for x86 for me, I'll watch your builders and see how it goes... This is now fixed. I'll send a complete build report after all builds are complete. Guenter
Re: [PATCH] clk: rockchip: Switch dt-binding headers for rk3328 to GPL/X11
On Sat, 23 Dec 2017 17:58:46 +0100 Heiko Stuebner wrote: > Am Samstag, 23. Dezember 2017, 17:53:45 CET schrieb Emmanuel Vadot: > > On Sat, 23 Dec 2017 17:15:06 +0100 > > Heiko Stuebner wrote: > > > > > Hi Emmanuel, > > > > > > Am Samstag, 23. Dezember 2017, 16:22:54 CET schrieb Emmanuel Vadot: > > > > Since those files are also needed kernel side, switch their licences > > > > to GPL/X11 so it can be used in BSD kernels. > > > > > > > > Signed-off-by: Emmanuel Vadot > > > > > > definitly no objection from me (especially as the file only contains > > > constant definitions, so copyrightability might be debateable), > > > but could you: > > > > > > (1) Adapt all rockchip clock headers in one patch, so we don't do this > > > for each header invididually > > > (2) Do the same for the power/rk3* headers, but in a separate patch > > > as this goes through a different tree > > > > Sure I can do that, will it be better to wait to have some kind of ack > > from someone from rockchip ? > > I don't know if China is somehow affected by the xmas season, but from what > I see, right now you only included Elaine (zhangq...@rock-chips.com) > but for example not the relevant list (linux-rockc...@lists.infradead.org). I've just git send using the output of get_maintainer.pl > But we also have some other points to clarify in the other subthread > started by Philippe, so it might be best to get the points he made sorted > before as well. > > > Heiko -- Emmanuel Vadot
Re: [PATCH] clk: rockchip: Switch dt-binding headers for rk3328 to GPL/X11
Am Samstag, 23. Dezember 2017, 17:53:45 CET schrieb Emmanuel Vadot: > On Sat, 23 Dec 2017 17:15:06 +0100 > Heiko Stuebner wrote: > > > Hi Emmanuel, > > > > Am Samstag, 23. Dezember 2017, 16:22:54 CET schrieb Emmanuel Vadot: > > > Since those files are also needed kernel side, switch their licences > > > to GPL/X11 so it can be used in BSD kernels. > > > > > > Signed-off-by: Emmanuel Vadot > > > > definitly no objection from me (especially as the file only contains > > constant definitions, so copyrightability might be debateable), > > but could you: > > > > (1) Adapt all rockchip clock headers in one patch, so we don't do this > > for each header invididually > > (2) Do the same for the power/rk3* headers, but in a separate patch > > as this goes through a different tree > > Sure I can do that, will it be better to wait to have some kind of ack > from someone from rockchip ? I don't know if China is somehow affected by the xmas season, but from what I see, right now you only included Elaine (zhangq...@rock-chips.com) but for example not the relevant list (linux-rockc...@lists.infradead.org). But we also have some other points to clarify in the other subthread started by Philippe, so it might be best to get the points he made sorted before as well. Heiko
Re: [PATCH] clk: rockchip: Switch dt-binding headers for rk3328 to GPL/X11
On Sat, 23 Dec 2017 17:15:06 +0100 Heiko Stuebner wrote: > Hi Emmanuel, > > Am Samstag, 23. Dezember 2017, 16:22:54 CET schrieb Emmanuel Vadot: > > Since those files are also needed kernel side, switch their licences > > to GPL/X11 so it can be used in BSD kernels. > > > > Signed-off-by: Emmanuel Vadot > > definitly no objection from me (especially as the file only contains > constant definitions, so copyrightability might be debateable), > but could you: > > (1) Adapt all rockchip clock headers in one patch, so we don't do this > for each header invididually > (2) Do the same for the power/rk3* headers, but in a separate patch > as this goes through a different tree Sure I can do that, will it be better to wait to have some kind of ack from someone from rockchip ? > > Thanks > Heiko > > > include/dt-bindings/clock/rk3328-cru.h | 44 > > ++-- > > include/dt-bindings/power/rk3328-power.h | 2 +- > > 2 files changed, 37 insertions(+), 9 deletions(-) > > > > diff --git a/include/dt-bindings/clock/rk3328-cru.h > > b/include/dt-bindings/clock/rk3328-cru.h > > index d2b26a4b43eb..bbcf03641f89 100644 > > --- a/include/dt-bindings/clock/rk3328-cru.h > > +++ b/include/dt-bindings/clock/rk3328-cru.h > > @@ -2,15 +2,43 @@ > > * Copyright (c) 2016 Rockchip Electronics Co. Ltd. > > * Author: Elaine > > * > > - * This program is free software; you can redistribute it and/or modify > > - * it under the terms of the GNU General Public License as published by > > - * the Free Software Foundation; either version 2 of the License, or > > - * (at your option) any later version. > > + * This file is dual-licensed: you can use it either under the terms > > + * of the GPL or the X11 license, at your option. Note that this dual > > + * licensing only applies to this file, and not this project as a > > + * whole. > > * > > - * This program is distributed in the hope that it will be useful, > > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > - * GNU General Public License for more details. > > + * a) This file is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU General Public License as > > + * published by the Free Software Foundation; either version 2 of the > > + * License, or (at your option) any later version. > > + * > > + * This file is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * Or, alternatively, > > + * > > + * b) Permission is hereby granted, free of charge, to any person > > + * obtaining a copy of this software and associated documentation > > + * files (the "Software"), to deal in the Software without > > + * restriction, including without limitation the rights to use, > > + * copy, modify, merge, publish, distribute, sublicense, and/or > > + * sell copies of the Software, and to permit persons to whom the > > + * Software is furnished to do so, subject to the following > > + * conditions: > > + * > > + * The above copyright notice and this permission notice shall be > > + * included in all copies or substantial portions of the Software. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > > + * OTHER DEALINGS IN THE SOFTWARE. > > */ > > > > #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H > > diff --git a/include/dt-bindings/power/rk3328-power.h > > b/include/dt-bindings/power/rk3328-power.h > > index 02e3d7fc1cce..301f30967b39 100644 > > --- a/include/dt-bindings/power/rk3328-power.h > > +++ b/include/dt-bindings/power/rk3328-power.h > > @@ -1,4 +1,4 @@ > > -/* SPDX-License-Identifier: GPL-2.0 */ > > +/* SPDX-License-Identifier: GPL-2.0 or X11 */ > > #ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__ > > #define __DT_BINDINGS_POWER_RK3328_POWER_H__ > > > > -- Emmanuel Vadot
Re: [PATCH] clk: rockchip: Switch dt-binding headers for rk3328 to GPL/X11
On Sat, 23 Dec 2017 17:19:58 +0100 Philippe Ombredanne wrote: > Dear Emmanuel, > > On Sat, Dec 23, 2017 at 4:22 PM, Emmanuel Vadot wrote: > > Since those files are also needed kernel side, switch their licences > > to GPL/X11 so it can be used in BSD kernels. > > > > Signed-off-by: Emmanuel Vadot > > --- > > include/dt-bindings/clock/rk3328-cru.h | 44 > > ++-- > > include/dt-bindings/power/rk3328-power.h | 2 +- > > 2 files changed, 37 insertions(+), 9 deletions(-) > > > > diff --git a/include/dt-bindings/clock/rk3328-cru.h > > b/include/dt-bindings/clock/rk3328-cru.h > > index d2b26a4b43eb..bbcf03641f89 100644 > > --- a/include/dt-bindings/clock/rk3328-cru.h > > +++ b/include/dt-bindings/clock/rk3328-cru.h > > @@ -2,15 +2,43 @@ > > * Copyright (c) 2016 Rockchip Electronics Co. Ltd. > > * Author: Elaine > > * > > - * This program is free software; you can redistribute it and/or modify > > - * it under the terms of the GNU General Public License as published by > > - * the Free Software Foundation; either version 2 of the License, or > > - * (at your option) any later version. > > + * This file is dual-licensed: you can use it either under the terms > > + * of the GPL or the X11 license, at your option. Note that this dual > > + * licensing only applies to this file, and not this project as a > > + * whole. > > * > > - * This program is distributed in the hope that it will be useful, > > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > - * GNU General Public License for more details. > > + * a) This file is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU General Public License as > > + * published by the Free Software Foundation; either version 2 of the > > + * License, or (at your option) any later version. > > + * > > + * This file is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * Or, alternatively, > > + * > > + * b) Permission is hereby granted, free of charge, to any person > > + * obtaining a copy of this software and associated documentation > > + * files (the "Software"), to deal in the Software without > > + * restriction, including without limitation the rights to use, > > + * copy, modify, merge, publish, distribute, sublicense, and/or > > + * sell copies of the Software, and to permit persons to whom the > > + * Software is furnished to do so, subject to the following > > + * conditions: > > + * > > + * The above copyright notice and this permission notice shall be > > + * included in all copies or substantial portions of the Software. > > + * > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > > + * OTHER DEALINGS IN THE SOFTWARE. > > */ > > You just poked a big pointy stick in my left eye. It hurts! Why not > use a proper SPDX tag here, like you did below? I've just used the same licence present on the DTS file. In one file there was just SPDX licence tags so I've keep it this way. > Each time such a long legalese is added to the kernel instead of an > SPDX tag there is an endangered animal species that disappears from > the face of the earth for good. You do not want to bear this grave > responsibility, do you? > > Also are you sure Elaine, other contributors and Rockchip Electronics > Co. Ltd. agree to this change? > It might be best if the patch were to come from them directly or at > least you will need proper acks for sure. I don't know if they agree, sending a patch seems the best way to know for me. > > > > #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H > > diff --git a/include/dt-bindings/power/rk3328-power.h > > b/include/dt-bindings/power/rk3328-power.h > > index 02e3d7fc1cce..301f30967b39 100644 > > --- a/include/dt-bindings/power/rk3328-power.h > > +++ b/include/dt-bindings/power/rk3328-power.h > > @@ -1,4 +1,4 @@ > > -/* SPDX-License-Identifier: GPL-2.0 */ > > +/* SPDX-License-Identifier: GPL-2.0 or X11 */ > > #ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__ > > #define __DT_BINDINGS_POWER_RK3328_POWER_H__ > > What you call X11 is called MIT in SPDX and in Thomas doc patches [1], > e.g. this tag is supposed to match the eyes-poking long legalese > above, this sh
Re: [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq
* Brian Norris [171222 23:23]: > + Rafael to this thread > > On Wed, Dec 20, 2017 at 11:19:12AM -0800, Tony Lindgren wrote: > > * Brian Norris [171219 00:50]: > > > On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote: > > > > > > Did this problem ever get resolved? To be clear, I believe the problem > > > at hand is: > > > > > > (a) in suspend/resume (not runtime PM; we may not even have runtime PM > > > support for most PCI devices) > > > > It seems it should be enough to implement runtime PM in the PCI > > controller. Isn't each PCI WAKE# line is wired from each PCI device > > to the PCI controller? > > No, not really. As discussed in later versions of this thread already, > the WAKE# hierarchy is orthogonal to the PCI hierarchy, and I think we > settled that it's reasonable to just consider this as a 1-per-device > thing, with each device "directly" attached to the PM controller. While > sharing could happen, that's something we decided to punt on...didn't > we? Sounds like we need a confirmation from some hardware people on this if the PCI device WAKE# can be wired to PCI controller or to a separate PM controller directly :) > > Then the PCI controller can figure out from which PCI device the > > WAKE# came from. > > I'm not completely sure of the details, but I believe this *can* be > determined by PME. But I'm not sure it's guaranteed to be supported, > especially in cases where we already have 1:1 WAKE#. So we should be > *trying* to report this wakeirq info from the device, if possible. If a PCI device has it's WAKE# wired directly to a PM controller instead of the PCI controller, then it seems that the PCI controller should be woken up and then presumably the regular PCI device interrupts will take care of the rest. Or else I'd say if the driver for the PCI device in some custom case needs to do something specific, then having that driver implement PM runtime makes sense. Naturally we want to avoid a dependency where all the possible drivers would need to implement PM runtime, I doubt that's needed though. Regards, Tony
Re: [PATCH] clk: rockchip: Switch dt-binding headers for rk3328 to GPL/X11
Hi, Am Samstag, 23. Dezember 2017, 17:19:58 CET schrieb Philippe Ombredanne: > Dear Emmanuel, > > On Sat, Dec 23, 2017 at 4:22 PM, Emmanuel Vadot wrote: > > Since those files are also needed kernel side, switch their licences > > to GPL/X11 so it can be used in BSD kernels. > > > > Signed-off-by: Emmanuel Vadot [...] > > diff --git a/include/dt-bindings/power/rk3328-power.h > > b/include/dt-bindings/power/rk3328-power.h > > index 02e3d7fc1cce..301f30967b39 100644 > > --- a/include/dt-bindings/power/rk3328-power.h > > +++ b/include/dt-bindings/power/rk3328-power.h > > @@ -1,4 +1,4 @@ > > -/* SPDX-License-Identifier: GPL-2.0 */ > > +/* SPDX-License-Identifier: GPL-2.0 or X11 */ > > #ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__ > > #define __DT_BINDINGS_POWER_RK3328_POWER_H__ > > What you call X11 is called MIT in SPDX and in Thomas doc patches [1], > e.g. this tag is supposed to match the eyes-poking long legalese > above, this should be instead: > > +/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */ > > Finally if the goal of this proposed license update is usage in > FreeBSD and other BSD kernels, why use MIT as a second license? Would > not a BSD be better and avoid license inflation on the BSD side? I think it is likely meant to match the license used on the devicetree files themselfs. For whatever reason the existing combination of GPL+MIT was the preferred one, so the license inflation is already there and it might be best to keep to the same combination for the headers needed by those devicetree files? Heiko
Re: [PATCH 4.4 00/78] 4.4.108-stable review
On Sat, Dec 23, 2017 at 08:13:48AM -0800, Guenter Roeck wrote:
> On 12/23/2017 06:46 AM, Greg Kroah-Hartman wrote:
> > On Sat, Dec 23, 2017 at 10:19:32AM +0100, Greg Kroah-Hartman wrote:
> > > On Fri, Dec 22, 2017 at 10:18:31AM -0800, Guenter Roeck wrote:
> > > > On Fri, Dec 22, 2017 at 09:45:41AM +0100, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 4.4.108 release.
> > > > > There are 78 patches in this series, all will be posted as a response
> > > > > to this one. If anyone has any issues with these being applied,
> > > > > please
> > > > > let me know.
> > > > >
> > > > > Responses should be made by Sun Dec 24 08:45:30 UTC 2017.
> > > > > Anything received after that time might be too late.
> > > > >
> > > >
> > > > I lost track with versions. This is with v4.4.107-79-g0989207.
> > > >
> > > > Build results:
> > > > total: 145 pass: 144 fail: 1
> > > > Failed builds:
> > > > alpha:allmodconfig
> > > > Qemu test results:
> > > > total: 118 pass: 118 fail: 0
> > > >
> > > > alpha/include/asm/mmu_context.h: In function 'ev5_switch_mm':
> > > > arch/alpha/include/asm/mmu_context.h:158:2: error: implicit declaration
> > > > of function 'task_thread_info'
> > > > arch/alpha/include/asm/mmu_context.h:158:24: error: invalid type
> > > > argument of '->' (have 'int')
> > > > alpha/include/asm/mmu_context.h: In function 'init_new_context':
> > > > arch/alpha/include/asm/mmu_context.h:236:24: error: invalid type
> > > > argument of '->' (have 'int')
> > > > arch/alpha/include/asm/mmu_context.h: In function 'enter_lazy_tlb':
> > > > arch/alpha/include/asm/mmu_context.h:250:23: error: invalid type
> > > > argument of '->' (have 'int')
> > > >
> > > > Didn't I already report this ?
> > >
> > > I thought that was a 4.9 issue. Let me look into this later today,
> > > thanks for the report...
> >
> > Hm, yeah, looks to be the same issue that 4.9 had. I resolve that by
> > ripping out the whole series, which I don't want to do here. Let me see
> > if I can resolve it simpler...
> >
>
> Apply 8ee912dab95f ("alpha: fix build failures") and fix conflict by picking
> the new include files. I am currently rebuilding with that applied to ensure
> that it breaks nothing else.
Now added, and pushed out, let me know how that goes.
Again, many thanks for your help here,
greg k-h
Re: [PATCH] clk: rockchip: Switch dt-binding headers for rk3328 to GPL/X11
Dear Emmanuel, On Sat, Dec 23, 2017 at 4:22 PM, Emmanuel Vadot wrote: > Since those files are also needed kernel side, switch their licences > to GPL/X11 so it can be used in BSD kernels. > > Signed-off-by: Emmanuel Vadot > --- > include/dt-bindings/clock/rk3328-cru.h | 44 > ++-- > include/dt-bindings/power/rk3328-power.h | 2 +- > 2 files changed, 37 insertions(+), 9 deletions(-) > > diff --git a/include/dt-bindings/clock/rk3328-cru.h > b/include/dt-bindings/clock/rk3328-cru.h > index d2b26a4b43eb..bbcf03641f89 100644 > --- a/include/dt-bindings/clock/rk3328-cru.h > +++ b/include/dt-bindings/clock/rk3328-cru.h > @@ -2,15 +2,43 @@ > * Copyright (c) 2016 Rockchip Electronics Co. Ltd. > * Author: Elaine > * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > + * This file is dual-licensed: you can use it either under the terms > + * of the GPL or the X11 license, at your option. Note that this dual > + * licensing only applies to this file, and not this project as a > + * whole. > * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > + * a) This file is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of the > + * License, or (at your option) any later version. > + * > + * This file is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * Or, alternatively, > + * > + * b) Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, > + * copy, modify, merge, publish, distribute, sublicense, and/or > + * sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following > + * conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > */ You just poked a big pointy stick in my left eye. It hurts! Why not use a proper SPDX tag here, like you did below? Each time such a long legalese is added to the kernel instead of an SPDX tag there is an endangered animal species that disappears from the face of the earth for good. You do not want to bear this grave responsibility, do you? Also are you sure Elaine, other contributors and Rockchip Electronics Co. Ltd. agree to this change? It might be best if the patch were to come from them directly or at least you will need proper acks for sure. > > #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H > diff --git a/include/dt-bindings/power/rk3328-power.h > b/include/dt-bindings/power/rk3328-power.h > index 02e3d7fc1cce..301f30967b39 100644 > --- a/include/dt-bindings/power/rk3328-power.h > +++ b/include/dt-bindings/power/rk3328-power.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 or X11 */ > #ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__ > #define __DT_BINDINGS_POWER_RK3328_POWER_H__ What you call X11 is called MIT in SPDX and in Thomas doc patches [1], e.g. this tag is supposed to match the eyes-poking long legalese above, this should be instead: +/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */ Finally if the goal of this proposed license update is usage in FreeBSD and other BSD kernels, why use MIT as a second license? Would not a BSD be better and avoid license inflation on the BSD side? [1] https://lkml.org/lkml/2017/12/4/934 -- Cordially Philippe Ombredanne
Re: [PATCH] clk: rockchip: Switch dt-binding headers for rk3328 to GPL/X11
Hi Emmanuel, Am Samstag, 23. Dezember 2017, 16:22:54 CET schrieb Emmanuel Vadot: > Since those files are also needed kernel side, switch their licences > to GPL/X11 so it can be used in BSD kernels. > > Signed-off-by: Emmanuel Vadot definitly no objection from me (especially as the file only contains constant definitions, so copyrightability might be debateable), but could you: (1) Adapt all rockchip clock headers in one patch, so we don't do this for each header invididually (2) Do the same for the power/rk3* headers, but in a separate patch as this goes through a different tree Thanks Heiko > include/dt-bindings/clock/rk3328-cru.h | 44 > ++-- > include/dt-bindings/power/rk3328-power.h | 2 +- > 2 files changed, 37 insertions(+), 9 deletions(-) > > diff --git a/include/dt-bindings/clock/rk3328-cru.h > b/include/dt-bindings/clock/rk3328-cru.h > index d2b26a4b43eb..bbcf03641f89 100644 > --- a/include/dt-bindings/clock/rk3328-cru.h > +++ b/include/dt-bindings/clock/rk3328-cru.h > @@ -2,15 +2,43 @@ > * Copyright (c) 2016 Rockchip Electronics Co. Ltd. > * Author: Elaine > * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > + * This file is dual-licensed: you can use it either under the terms > + * of the GPL or the X11 license, at your option. Note that this dual > + * licensing only applies to this file, and not this project as a > + * whole. > * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > + * a) This file is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of the > + * License, or (at your option) any later version. > + * > + * This file is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * Or, alternatively, > + * > + * b) Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, > + * copy, modify, merge, publish, distribute, sublicense, and/or > + * sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following > + * conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > */ > > #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H > diff --git a/include/dt-bindings/power/rk3328-power.h > b/include/dt-bindings/power/rk3328-power.h > index 02e3d7fc1cce..301f30967b39 100644 > --- a/include/dt-bindings/power/rk3328-power.h > +++ b/include/dt-bindings/power/rk3328-power.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 or X11 */ > #ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__ > #define __DT_BINDINGS_POWER_RK3328_POWER_H__ > >
Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature
On Sat, Dec 23, 2017 at 03:53:57PM +, Ghorai, Sukumar wrote: > >> > included in 4.14-rc1, so something needs to be done in Linus's tree > >> > to resolve this issue, otherwise people will hit this as a > >> > regression when moving to 4.14 or newer. > >> > >> Well, I wouldn't object to reverting it in Linus' tree too, since > >> AFAIK, this is something that can be configured by user-space policy, > >> no? And that way, no user space is surprised by the sudden additional > >> requirements on managing bluetooth wakeup. > Wakeup from Bluetooth will be observed as long as USB wakeup is configured > from > user space or kernel space or connected to any Bluetooth HID devices. > And we don't want to support the wakeup from BT HID devide. > The solution looks like disable Bluetooth in S3 entry? > Looks we are trying to hide the other problems in a system, and reverting > this patch. > > > > >I agree, please work with the bluetooth developers to make this happen. > >They seem to be ignoring patches right now, so you might have to kick them a > >few > >times :( > Do you suggest submitter to send the revert request to 4.12 and 4.14 kernel? 4.12 is long end-of-life, I don't know what you expect to happen there. 4.14 is already released, this needs to be done for 4.15 first, right? thanks, greg k-h
Re: [PATCH 4.4 00/78] 4.4.108-stable review
On 12/23/2017 06:46 AM, Greg Kroah-Hartman wrote:
On Sat, Dec 23, 2017 at 10:19:32AM +0100, Greg Kroah-Hartman wrote:
On Fri, Dec 22, 2017 at 10:18:31AM -0800, Guenter Roeck wrote:
On Fri, Dec 22, 2017 at 09:45:41AM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.108 release.
There are 78 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Dec 24 08:45:30 UTC 2017.
Anything received after that time might be too late.
I lost track with versions. This is with v4.4.107-79-g0989207.
Build results:
total: 145 pass: 144 fail: 1
Failed builds:
alpha:allmodconfig
Qemu test results:
total: 118 pass: 118 fail: 0
alpha/include/asm/mmu_context.h: In function 'ev5_switch_mm':
arch/alpha/include/asm/mmu_context.h:158:2: error: implicit declaration of
function 'task_thread_info'
arch/alpha/include/asm/mmu_context.h:158:24: error: invalid type argument of
'->' (have 'int')
alpha/include/asm/mmu_context.h: In function 'init_new_context':
arch/alpha/include/asm/mmu_context.h:236:24: error: invalid type argument of
'->' (have 'int')
arch/alpha/include/asm/mmu_context.h: In function 'enter_lazy_tlb':
arch/alpha/include/asm/mmu_context.h:250:23: error: invalid type argument of
'->' (have 'int')
Didn't I already report this ?
I thought that was a 4.9 issue. Let me look into this later today,
thanks for the report...
Hm, yeah, looks to be the same issue that 4.9 had. I resolve that by
ripping out the whole series, which I don't want to do here. Let me see
if I can resolve it simpler...
Apply 8ee912dab95f ("alpha: fix build failures") and fix conflict by picking
the new include files. I am currently rebuilding with that applied to ensure
that it breaks nothing else.
Guenter
Re: [PATCH] staging: vc04_services: Prefer BUG_ON instead of if condition followed by BUG.
Hi Kishore, > kishor...@techveda.org hat am 23. Dezember 2017 um 16:06 geschrieben: > > > From: Kishore KP > > Use BUG_ON instead of if condition followed by BUG. > Pointed out by Coccinelle. > > Signed-off-by: Kishore KP > Signed-off-by: Suniel Mahesh > --- > Note: > - Patch was compile tested and built(ARCH=arm) on linux-next > (latest). > - No build issues reported. > --- > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git > a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c > b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c > index 315b49c..7116f61 100644 > --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c > @@ -224,8 +224,7 @@ int vchiq_platform_init(struct platform_device *pdev, > VCHIQ_STATE_T *state) > > platform_state = (struct vchiq_2835_state *)state->platform_state; > > - if (!platform_state->inited) > - BUG(); > + BUG_ON(!platform_state->inited); > vchiq isn't critical so i prefer WARN_ON_ONCE() here. Thanks Stefan
Re: kasan for bpf
From: Alexei Starovoitov Date: Fri, 22 Dec 2017 20:31:56 -0800 > Thoughts? Even though you propose it as the opposite, it sounds like a crutch for the verifier. If we strictly control objects that the eBPF program can access, verifier ensures this, and all other objects go through helpers, then I cannot see what kasan for bpf can buy us. To me it tells the world "yes, verifier and carefully designed helpers are insufficient" and that's not the message I have been giving to rooms full of hundreds of people listening to my xdp/bpf presentations.
Re: [PATCH v5 6/6] [media] cxusb: add analog mode support for Medion MD95700
On Sat, Dec 23, 2017 at 12:19 AM, Maciej S. Szmigiero wrote: > This patch adds support for analog part of Medion 95700 in the cxusb > driver. > > What works: > * Video capture at various sizes with sequential fields, > * Input switching (TV Tuner, Composite, S-Video), > * TV and radio tuning, > * Video standard switching and auto detection, > * Radio mode switching (stereo / mono), > * Unplugging while capturing, > * DVB / analog coexistence, > * Raw BT.656 stream support. > > What does not work yet: > * Audio, > * VBI, > * Picture controls. > > Signed-off-by: Maciej S. Szmigiero > --- > drivers/media/usb/dvb-usb/Kconfig| 16 +- > drivers/media/usb/dvb-usb/Makefile |3 + > drivers/media/usb/dvb-usb/cxusb-analog.c | 1914 > ++ > drivers/media/usb/dvb-usb/cxusb.c|2 - > drivers/media/usb/dvb-usb/cxusb.h| 106 ++ > 5 files changed, 2037 insertions(+), 4 deletions(-) > create mode 100644 drivers/media/usb/dvb-usb/cxusb-analog.c > index ..969d82b24f41 > --- /dev/null > +++ b/drivers/media/usb/dvb-usb/cxusb-analog.c > @@ -0,0 +1,1914 @@ > +// SPDX-License-Identifier: GPL-2.0+ Thanks! For the SPDX tags usage: Acked-by: Philippe Ombredanne
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
On 12/23/2017 05:48 AM, Greg KH wrote: On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote: Hi all, When I tried to use devm_ioremap function and review related code, I found devm_ioremap and devm_ioremap_nocache is almost the same with each other, except one use ioremap while the other use ioremap_nocache. For all arches? Really? Look at MIPS, and x86, they have different functions. Both mips and x86 end up mapping the same function, but other arches don't. mn10300 is one where ioremap and ioremap_nocache are definitely different. Guenter While ioremap's default function is ioremap_nocache, so devm_ioremap_nocache also have the same function with devm_ioremap, which can just be killed to reduce the size of devres.o(from 20304 bytes to 18992 bytes in my compile environment). I have posted two versions, which use macro instead of function for devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill devm_ioremap_nocache for no need to keep a macro around for the duplicate thing. So here comes v3 and please help to review. I don't think this can be done, what am I missing? These functions are not identical, sorry for missing that before. thanks, greg k-h
RE: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature
>> > included in 4.14-rc1, so something needs to be done in Linus's tree >> > to resolve this issue, otherwise people will hit this as a >> > regression when moving to 4.14 or newer. >> >> Well, I wouldn't object to reverting it in Linus' tree too, since >> AFAIK, this is something that can be configured by user-space policy, >> no? And that way, no user space is surprised by the sudden additional >> requirements on managing bluetooth wakeup. Wakeup from Bluetooth will be observed as long as USB wakeup is configured from user space or kernel space or connected to any Bluetooth HID devices. And we don't want to support the wakeup from BT HID devide. The solution looks like disable Bluetooth in S3 entry? Looks we are trying to hide the other problems in a system, and reverting this patch. > >I agree, please work with the bluetooth developers to make this happen. >They seem to be ignoring patches right now, so you might have to kick them a >few >times :( Do you suggest submitter to send the revert request to 4.12 and 4.14 kernel?
Re: [PATCH] clk: mediatek: Fix all warnings for missing struct clk_onecell_data
On Sat, 2017-12-23 at 12:20 +0100, Jean Delvare wrote:
> Hi Sean,
>
> On Sat, 23 Dec 2017 15:56:36 +0800, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > In fact, the clk-mtk.h header is unnecessary for reset.c and thus it's
> > safe to remove it from the file to get rid of below build warnings.
> >
> > All warnings (new ones prefixed by >>):
> >
> >In file included from drivers/clk/mediatek/reset.c:22:0:
> > >>drivers/clk/mediatek/clk-mtk.h:44:19: warning: 'struct clk_onecell_data'
> > declared inside parameter list will not be visible outside of
> > this definition or declaration
> > int num, struct clk_onecell_data *clk_data);
> > ^~~~
> > drivers/clk/mediatek/clk-mtk.h:63:19: warning: 'struct clk_onecell_data'
> > declared inside parameter list will not be visible outside of
> > this definition or declaration
> > int num, struct clk_onecell_data *clk_data);
> > ^~~~
> > drivers/clk/mediatek/clk-mtk.h:145:10: warning: 'struct clk_onecell_data'
> > declared inside parameter list will not be visible outside of
> > this definition or declaration
> > struct clk_onecell_data *clk_data);
> > ^~~~
> > drivers/clk/mediatek/clk-mtk.h:164:11: warning: 'struct clk_onecell_data'
> > declared inside parameter list will not be visible outside of
> > this definition or declaration
> >struct clk_onecell_data *clk_data);
> > ^~~~
> > drivers/clk/mediatek/clk-mtk.h:190:12: warning: 'struct clk_onecell_data'
> > declared inside parameter list will not be visible outside of this
> > definition or declaration
> > struct clk_onecell_data *clk_data);
> >^~~~
>
> That's not the proper fix. The actual problem here is in clk-mtk.h,
> which declares functions which need struct clk_onecell_data without
> declaring that structure first. This can be fixed in 2 ways:
>
> 1* #Include whatever header file provides the definition of struct
>clk_onecell_data (I think ) in clk-mtk.h
>itself.
>
> 2* As you only manipulate pointers and not the structure itself, you
>could simply declare that this struct exists, without defining it,
>prior to referencing it in clk-mtk.h. As easy as:
>
>struct clk_onecell_data;
>
> In this case option 1 seems preferable.
>
> The reason why the problem is only visible in reset.c is because other
> source files under drivers/clk/mediatek #include
> explicitly before #including clk-mtk.h. But it only works "by
> accident". Ideally header files should be self-sufficient, so you don't
> depend on #include order.
>
agreed on above. I also prefer using option 1 to solve original issue.
> > Reported-by: kbuild test robot
> > Signed-off-by: Sean Wang
> > Cc: kbuild-...@01.org
> > Cc: Stephen Boyd
> > Cc: linux-...@vger.kernel.org
> > ---
> > drivers/clk/mediatek/reset.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/clk/mediatek/reset.c b/drivers/clk/mediatek/reset.c
> > index d3551d5..70ebb2e 100644
> > --- a/drivers/clk/mediatek/reset.c
> > +++ b/drivers/clk/mediatek/reset.c
> > @@ -19,8 +19,6 @@
> > #include
> > #include
> >
> > -#include "clk-mtk.h"
> > -
> > struct mtk_reset {
> > struct regmap *regmap;
> > int regofs;
>
> If the header file is indeed not needed then that's still a good
> change, even if it doesn't fix the problem, so:
>
> Reviewed-by: Jean Delvare
> However the patch description should be adjusted accordingly.
I will use another patch to remove the indeed not needed header
thanks a lot for your detailed explanation and help
Sean
[PATCH] Staging: wlan-ng: hfa384x_usb: fixed two line limit coding style issues
Fixed two coding style issues.
Signed-off-by: Andy Pusch
---
drivers/staging/wlan-ng/hfa384x_usb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 197f5a914e8f..d6df35e1745c 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -2457,7 +2457,8 @@ int hfa384x_drvr_start(struct hfa384x *hw)
* ok
*/
result =
- usb_get_std_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_in,
&status);
+ usb_get_std_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_in,
+ &status);
if (result < 0) {
netdev_err(hw->wlandev->netdev, "Cannot get bulk in endpoint
status.\n");
goto done;
@@ -2466,7 +2467,8 @@ int hfa384x_drvr_start(struct hfa384x *hw)
netdev_err(hw->wlandev->netdev, "Failed to reset bulk in
endpoint.\n");
result =
- usb_get_std_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_out,
&status);
+ usb_get_std_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_out,
+ &status);
if (result < 0) {
netdev_err(hw->wlandev->netdev, "Cannot get bulk out endpoint
status.\n");
goto done;
--
2.15.1
Re: [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2
On Sat, 2017-12-23 at 08:52 +0100, Matthias Brugger wrote:
>
> On 12/22/2017 07:06 AM, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > On bpi-r2 board, totally there're four uarts which we usually called
> > uart[0-3] helpful to extend slow I/O devices. Among those ones, uart2 has
> > dedicated pin slot which is used to conolse log. uart[0-1] appear at the
> > 40-pins connector and uart3 has no pinout, but just has test points (TP47
> > for TX and TP48 for RX, respectively) nearby uart2. Also, some missing
> > pinctrl is being complemented for those devices.
> >
> > Signed-off-by: Sean Wang
> > ---
> > arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 26
> > --
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> > b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> > index 7bf5aa2..64bf5db 100644
> > --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> > +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> > @@ -409,6 +409,20 @@
> > ;
> > };
> > };
> > +
> > + uart2_pins_a: uart@2 {
> > + pins_dat {
> > + pinmux = ,
> > +;
> > + };
> > + };
> > +
> > + uart3_pins_a: uart@3 {
> > + pins_dat {
> > + pinmux = ,
> > +;
> > + };
> > + };
> > };
> >
> > &pwm {
> > @@ -454,16 +468,24 @@
> > &uart0 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&uart0_pins_a>;
> > - status = "disabled";
> > + status = "okay";
> > };
> >
> > &uart1 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&uart1_pins_a>;
> > - status = "disabled";
> > + status = "okay";
> > };
> >
> > &uart2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&uart2_pins_a>;
> > + status = "okay";
> > +};
> > +
> > +&uart3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&uart3_pins_a>;
> > status = "okay";
> > };
> >
>
> Why do we want to enable uart3 when there are only test points?
> It is not very useful, or do I oversee something?
>
I have been listening to the sound from potential users of bpi-r2 to
understand what assistance I have to provide to them. Something could
be seen through [1] in the forum to know they had been trying hard to
explore all available UARTs from the SoC in the last weeks. The patch
should be really useful for these people and for the extra soldering
it shouldn't become a problem for these makers.
[1] http://forum.banana-pi.org/t/gpio-uart-not-the-debug-port/3748
Sean
> Regards,
> Matthias
>
[PATCH] clk: rockchip: Switch dt-binding headers for rk3328 to GPL/X11
Since those files are also needed kernel side, switch their licences to GPL/X11 so it can be used in BSD kernels. Signed-off-by: Emmanuel Vadot --- include/dt-bindings/clock/rk3328-cru.h | 44 ++-- include/dt-bindings/power/rk3328-power.h | 2 +- 2 files changed, 37 insertions(+), 9 deletions(-) diff --git a/include/dt-bindings/clock/rk3328-cru.h b/include/dt-bindings/clock/rk3328-cru.h index d2b26a4b43eb..bbcf03641f89 100644 --- a/include/dt-bindings/clock/rk3328-cru.h +++ b/include/dt-bindings/clock/rk3328-cru.h @@ -2,15 +2,43 @@ * Copyright (c) 2016 Rockchip Electronics Co. Ltd. * Author: Elaine * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. */ #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H diff --git a/include/dt-bindings/power/rk3328-power.h b/include/dt-bindings/power/rk3328-power.h index 02e3d7fc1cce..301f30967b39 100644 --- a/include/dt-bindings/power/rk3328-power.h +++ b/include/dt-bindings/power/rk3328-power.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 */ +/* SPDX-License-Identifier: GPL-2.0 or X11 */ #ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__ #define __DT_BINDINGS_POWER_RK3328_POWER_H__ -- 2.14.2
[PATCH 2/2] lib: Remove module auto-unloading which encourages inconsistent behaviour
The module auto-unload might seem like a nice optimization, but
it encourages inconsistent behaviour. And behaviour that is
different from all other normal modules.
rbtree_test.c and percpu_test.c returns -EAGAIN from module_init()
on successful completion. Normal module return 0 on success but
returning -EAGAIN perform auto module unloading which seem like
a nice optimization but it brings inconsistent behaviour as well.
I face the similar problem in my previous patch, "Paul Gortmaker"
gives nice review comment on module auto-unloading brings
inconsistent behaviour.
Imagine something as simple as this:
for i in $LIST ; do
modprobe $i
lsmod | grep -q $i
if [ $? != 0 ]; then echo Module $i is not present! ; fi
done
OK, not ideal code, ignoring the modprobe return -- but what it reports
is true --
rbtree_test.c and percpu_test.c test module (if it passed) will NOT be
present.
All other modules from linux/lib/* follow the same semantics that
module_init() returns 0 on successful completion & let external entity
like rmmod do the module unloading task.
Signed-off-by: Pravin Shedge
---
lib/percpu_test.c | 3 ++-
lib/rbtree_test.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/percpu_test.c b/lib/percpu_test.c
index 0b5d14d..57a637b 100644
--- a/lib/percpu_test.c
+++ b/lib/percpu_test.c
@@ -123,7 +123,8 @@ static int __init percpu_test_init(void)
preempt_enable();
pr_info("percpu test done\n");
- return -EAGAIN; /* Fail will directly unload the module */
+
+ return 0;
}
static void __exit percpu_test_exit(void)
diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index 7d36c1e..5c52112 100644
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -394,7 +394,7 @@ static int __init rbtree_test_init(void)
kfree(nodes);
- return -EAGAIN; /* Fail will directly unload the module */
+ return 0;
}
static void __exit rbtree_test_exit(void)
--
2.7.4
Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device
[...] > > So IMO the changes you are proposing make sense regardless of the > genpd issue, because they generally simplify the phy code, but the > additional use_runtime_pm field in struct phy represents redundant > information (manipulating reference counters shouldn't matter if > runtime PM is disabled), so it doesn't appear to be necessary. > Actually, the first version I posted treated the return codes from pm_runtime_get_sync() according to your suggestion above. However, Kishon pointed out that it didn't work. That's because, there are phy provider drivers that enables runtime PM *after* calling phy_create(). And in those cases, that is because they want to treat runtime PM themselves. I think that's probably something we should look into to change, but I find it being a separate issue, that I didn't want to investigate as part of this series. See more about the thread here: https://www.spinics.net/lists/linux-renesas-soc/msg21711.html > [On a related note, I'm not sure why phy tries to intercept runtime PM > errors and "fix up" the reference counters. That doesn't look right > to me at all.] > > That said, the current phy code is not strictly invalid. While it > looks more complicated than necessary, it doesn't do things documented > as invalid in principle, so saying "The behaviour around the runtime > PM deployment cause some issues during system suspend" in the > changelog is describing the problem from a very specific angle. > Simply put, pm_runtime_force_suspend() and the current phy code cannot > work together and so using them together is a bug. None of them > individually is at fault, but combining them is incorrect. > > Fortunately enough, the phy code can be modified so that it can be > used with pm_runtime_force_suspend() without problems, but picturing > it as "problematic", because it cannot do that today is not entirely > fair IMO. Right, this makes sense. Let me clarify this in the changelog. Kind regards Uffe
[PATCH] staging: vc04_services: Prefer BUG_ON instead of if condition followed by BUG.
From: Kishore KP Use BUG_ON instead of if condition followed by BUG. Pointed out by Coccinelle. Signed-off-by: Kishore KP Signed-off-by: Suniel Mahesh --- Note: - Patch was compile tested and built(ARCH=arm) on linux-next (latest). - No build issues reported. --- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c index 315b49c..7116f61 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c @@ -224,8 +224,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state) platform_state = (struct vchiq_2835_state *)state->platform_state; - if (!platform_state->inited) - BUG(); + BUG_ON(!platform_state->inited); return &platform_state->arm_state; } -- 1.9.1
