Re: Does uaccess_kernel() work for detecting kernel thread?
On Tue, Dec 22, 2020 at 11:33:58AM -0600, Eric W. Biederman wrote: > I do wonder though if perhaps we should create a is_user_cred helper to > detect the difference between the creds of kernel threads and the thread > of ordinary userspace. Which would handle io_uring that copy creds > around and check them at a later time more cleanly. I don't think we should as no one has a business to check this difference. If there is a case where the creds are not correct for all access decisions we need to fix that rather than adding hacks.
Re: [PATCH] ubifs: Fix memleak in ubifs_init_authentication
在 2021/1/5 14:03, Dinghao Liu 写道:
When crypto_shash_digestsize() fails, c->hmac_tfm
has not been freed before returning, which leads
to memleak.
Fixes: 49525e5eecca5 ("ubifs: Add helper functions for authentication support")
Signed-off-by: Dinghao Liu
Reviewed-by: Zhihao Cheng
---
fs/ubifs/auth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index 51a7c8c2c3f0..e564d5ff8781 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -327,7 +327,7 @@ int ubifs_init_authentication(struct ubifs_info *c)
ubifs_err(c, "hmac %s is bigger than maximum allowed hmac size (%d >
%d)",
hmac_name, c->hmac_desc_len, UBIFS_HMAC_ARR_SZ);
err = -EINVAL;
- goto out_free_hash;
+ goto out_free_hmac;
}
err = crypto_shash_setkey(c->hmac_tfm, ukp->data, ukp->datalen);
Re: [PATCH] iommu: check for the deferred attach when attaching a device
在 2021年01月05日 11:55, lijiang 写道:
> Hi,
>
> Also add Joerg to cc list.
>
Also add more people to cc list, Jerry Snitselaar and Tom Lendacky.
Thanks.
> Thanks.
> Lianbo
> 在 2020年12月26日 13:39, Lianbo Jiang 写道:
>> Currently, because domain attach allows to be deferred from iommu
>> driver to device driver, and when iommu initializes, the devices
>> on the bus will be scanned and the default groups will be allocated.
>>
>> Due to the above changes, some devices could be added to the same
>> group as below:
>>
>> [3.859417] pci :01:00.0: Adding to iommu group 16
>> [3.864572] pci :01:00.1: Adding to iommu group 16
>> [3.869738] pci :02:00.0: Adding to iommu group 17
>> [3.874892] pci :02:00.1: Adding to iommu group 17
>>
>> But when attaching these devices, it doesn't allow that a group has
>> more than one device, otherwise it will return an error. This conflicts
>> with the deferred attaching. Unfortunately, it has two devices in the
>> same group for my side, for example:
>>
>> [9.627014] iommu_group_device_count(): device name[0]::01:00.0
>> [9.633545] iommu_group_device_count(): device name[1]::01:00.1
>> ...
>> [ 10.255609] iommu_group_device_count(): device name[0]::02:00.0
>> [ 10.262144] iommu_group_device_count(): device name[1]::02:00.1
>>
>> Finally, which caused the failure of tg3 driver when tg3 driver calls
>> the dma_alloc_coherent() to allocate coherent memory in the tg3_test_dma().
>>
>> [9.660310] tg3 :01:00.0: DMA engine test failed, aborting
>> [9.754085] tg3: probe of :01:00.0 failed with error -12
>> [9.997512] tg3 :01:00.1: DMA engine test failed, aborting
>> [ 10.043053] tg3: probe of :01:00.1 failed with error -12
>> [ 10.288905] tg3 :02:00.0: DMA engine test failed, aborting
>> [ 10.334070] tg3: probe of :02:00.0 failed with error -12
>> [ 10.578303] tg3 :02:00.1: DMA engine test failed, aborting
>> [ 10.622629] tg3: probe of :02:00.1 failed with error -12
>>
>> In addition, the similar situations also occur in other drivers such
>> as the bnxt_en driver. That can be reproduced easily in kdump kernel
>> when SME is active.
>>
>> Add a check for the deferred attach in the iommu_attach_device() and
>> allow to attach the deferred device regardless of how many devices
>> are in a group.
>>
>> Signed-off-by: Lianbo Jiang
>> ---
>> drivers/iommu/iommu.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index ffeebda8d6de..dccab7b133fb 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -1967,8 +1967,11 @@ int iommu_attach_device(struct iommu_domain *domain,
>> struct device *dev)
>> */
>> mutex_lock(>mutex);
>> ret = -EINVAL;
>> -if (iommu_group_device_count(group) != 1)
>> +if (!iommu_is_attach_deferred(domain, dev) &&
>> +iommu_group_device_count(group) != 1) {
>> +dev_err_ratelimited(dev, "Group has more than one device\n");
>> goto out_unlock;
>> +}
>>
>> ret = __iommu_attach_group(domain, group);
>>
>>
[PATCH] drm/amdgpu:fix IH overflow on Tonga
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2").
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR doesn't trigger another memory writeback.
So what can happen is that we end up processing the buffer overflow over and
over again because the bit is never cleared. Resulting in a random system
lockup because of an infinite loop in an interrupt handler.
Signed-off-by: Defang Bo
---
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
index e40140bf6699..9c5947976717 100644
--- a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
@@ -195,19 +195,28 @@ static u32 tonga_ih_get_wptr(struct amdgpu_device *adev,
wptr = le32_to_cpu(*ih->wptr_cpu);
- if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
- wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
- /* When a ring buffer overflow happen start parsing interrupt
-* from the last not overwritten vector (wptr + 16). Hopefully
-* this should allow us to catchup.
-*/
- dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
-wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
- ih->rptr = (wptr + 16) & ih->ptr_mask;
- tmp = RREG32(mmIH_RB_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
- WREG32(mmIH_RB_CNTL, tmp);
- }
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = RREG32(mmIH_RB_CNTL);
+
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
+
+ /* When a ring buffer overflow happen start parsing interrupt
+* from the last not overwritten vector (wptr + 16). Hopefully
+* this should allow us to catchup.
+*/
+ dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
+ wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
+ ih->rptr = (wptr + 16) & ih->ptr_mask;
+ tmp = RREG32(mmIH_RB_CNTL);
+ tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
+ WREG32(mmIH_RB_CNTL, tmp);
+
+out:
return (wptr & ih->ptr_mask);
}
--
2.7.4
Re: [PATCH RESEND] ia64: remove duplicate entries in generic_defconfig
Looks good, Reviewed-by: Christoph Hellwig
Re: uninitialized pmem struct pages
On Mon 04-01-21 21:17:43, Dan Williams wrote: > On Mon, Jan 4, 2021 at 2:45 AM David Hildenbrand wrote: [...] > > I believe Dan mentioned somewhere that he wants to see a real instance > > of this producing a BUG before actually moving forward with a fix. I > > might be wrong. > > I think I'm missing an argument for the user-visible effects of the > "Bad." statements above. I think soft_offline_page() is a candidate > for a local fix because mm/memory-failure.c already has a significant > amount of page-type specific knowledge. So teaching it "yes" for > MEMORY_DEVICE_PRIVATE-ZONE_DEVICE and "no" for other ZONE_DEVICE seems > ok to me. I believe we do not want to teach _every_ pfn walker about zone device pages. This would be quite error prone. Especially when a missig check could lead to a silently broken data or BUG_ON with debugging enabled (which is not the case for many production users). Or are we talking about different bugs here? -- Michal Hocko SUSE Labs
Re: [RFC PATCH V3 1/1] block: reject I/O for same fd if block size changed
On Tue, Jan 05, 2021 at 10:04:56AM +0900, Minwoo Im wrote: > It was a point that I really would like to ask by RFC whether we can > have backpointer to the gendisk from the request_queue. And I'd like to > have it to simplify this routine and for future usages also. I think it is the right thing to do, at least mid-term, although I don't want to enforce the burden on you right now. > I will restrict this one by checking GENHD_FL_UP flag from the gendisk > for the next patch. > > > > > Alternatively we could make this request_queue QUEUE* flag for now. > > As this patch rejects I/O from the block layer partition code, can we > have this flag in gendisk rather than request_queue ? For now we can as the request_queue is required. I have some plans to clean up this area, but just using a request_queue flag for now is probably the simplest, even if it means more work for me later.
Re: [PATCH] fs: Fix freeze_bdev()/thaw_bdev() accounting of bd_fsfreeze_sb
Looks good, Reviewed-by: Christoph Hellwig
[PATCH v3 1/4] mm: rename memmap_init() and memmap_init_zone()
The current memmap_init_zone() only handles memory region inside one zone,
actually memmap_init() does the memmap init of one zone. So rename both of
them accordingly.
And also rename the function parameter 'range_start_pfn' and local variable
'range_end_pfn' of memmap_init() to zone_start_pfn/zone_end_pfn.
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
---
arch/ia64/include/asm/pgtable.h | 2 +-
arch/ia64/mm/init.c | 6 +++---
include/linux/mm.h | 2 +-
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 24
5 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 779b6972aa84..dce2ff37df65 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -520,7 +520,7 @@ extern struct page *zero_page_memmap_ptr;
# ifdef CONFIG_VIRTUAL_MEM_MAP
/* arch mem_map init routine is needed due to holes in a virtual mem_map */
-extern void memmap_init (unsigned long size, int nid, unsigned long zone,
+extern void memmap_init_zone(unsigned long size, int nid, unsigned long
zone,
unsigned long start_pfn);
# endif /* CONFIG_VIRTUAL_MEM_MAP */
# endif /* !__ASSEMBLY__ */
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index e76386a3479e..c8e68e92beb3 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -535,18 +535,18 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
/ sizeof(struct page));
if (map_start < map_end)
- memmap_init_zone((unsigned long)(map_end - map_start),
+ memmap_init_range((unsigned long)(map_end - map_start),
args->nid, args->zone, page_to_pfn(map_start),
page_to_pfn(map_end),
MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
return 0;
}
void __meminit
-memmap_init (unsigned long size, int nid, unsigned long zone,
+memmap_init_zone(unsigned long size, int nid, unsigned long zone,
unsigned long start_pfn)
{
if (!vmem_map) {
- memmap_init_zone(size, nid, zone, start_pfn, start_pfn + size,
+ memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
} else {
struct page *start;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 6b3de3c09cd5..26c01f5a028b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2439,7 +2439,7 @@ extern int __meminit early_pfn_to_nid(unsigned long pfn);
#endif
extern void set_dma_reserve(unsigned long new_dma_reserve);
-extern void memmap_init_zone(unsigned long, int, unsigned long,
+extern void memmap_init_range(unsigned long, int, unsigned long,
unsigned long, unsigned long, enum meminit_context,
struct vmem_altmap *, int migratetype);
extern void setup_per_zone_wmarks(void);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index f9d57b9be8c7..ddcb1cd24c60 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -713,7 +713,7 @@ void __ref move_pfn_range_to_zone(struct zone *zone,
unsigned long start_pfn,
* expects the zone spans the pfn range. All the pages in the range
* are reserved so nobody should be touching them so we should be safe
*/
- memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn, 0,
+ memmap_init_range(nr_pages, nid, zone_idx(zone), start_pfn, 0,
MEMINIT_HOTPLUG, altmap, migratetype);
set_zone_contiguous(zone);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3ea9d5cd6058..69ebf75be91c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6117,7 +6117,7 @@ overlap_memmap_init(unsigned long zone, unsigned long
*pfn)
* (usually MIGRATE_MOVABLE). Besides setting the migratetype, no related
* zone stats (e.g., nr_isolate_pageblock) are touched.
*/
-void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long
zone,
+void __meminit memmap_init_range(unsigned long size, int nid, unsigned long
zone,
unsigned long start_pfn, unsigned long zone_end_pfn,
enum meminit_context context,
struct vmem_altmap *altmap, int migratetype)
@@ -6292,24 +6292,24 @@ static inline u64 init_unavailable_range(unsigned long
spfn, unsigned long epfn,
}
#endif
-void __init __weak memmap_init(unsigned long size, int nid,
+void __init __weak memmap_init_zone(unsigned long size, int nid,
unsigned long zone,
- unsigned long range_start_pfn)
+ unsigned long zone_start_pfn)
{
unsigned long start_pfn, end_pfn, hole_start_pfn = 0;
- unsigned long range_end_pfn = range_start_pfn + size;
+ unsigned long zone_end_pfn = zone_start_pfn + size;
[PATCH v3 4/4] mm: remove unneeded local variable in free_area_init_core
Local variable 'zone_start_pfn' is not needed since there's only
one call site in free_area_init_core(). Let's remove it and pass
zone->zone_start_pfn directly to init_currently_empty_zone().
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
---
mm/page_alloc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e0ce6fb6373b..9cacb8652239 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6986,7 +6986,6 @@ static void __init free_area_init_core(struct pglist_data
*pgdat)
for (j = 0; j < MAX_NR_ZONES; j++) {
struct zone *zone = pgdat->node_zones + j;
unsigned long size, freesize, memmap_pages;
- unsigned long zone_start_pfn = zone->zone_start_pfn;
size = zone->spanned_pages;
freesize = zone->present_pages;
@@ -7035,7 +7034,7 @@ static void __init free_area_init_core(struct pglist_data
*pgdat)
set_pageblock_order();
setup_usemap(zone);
- init_currently_empty_zone(zone, zone_start_pfn, size);
+ init_currently_empty_zone(zone, zone->zone_start_pfn, size);
memmap_init_zone(zone);
}
}
--
2.17.2
[PATCH v3 2/4] mm: simplify parater of function memmap_init_zone()
As David suggested, simply passing 'struct zone *zone' is enough. We can
get all needed information from 'struct zone*' easily.
Suggested-by: David Hildenbrand
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
---
arch/ia64/include/asm/pgtable.h | 3 +--
arch/ia64/mm/init.c | 12 +++-
mm/page_alloc.c | 20 ++--
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index dce2ff37df65..2c81394a2430 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -520,8 +520,7 @@ extern struct page *zero_page_memmap_ptr;
# ifdef CONFIG_VIRTUAL_MEM_MAP
/* arch mem_map init routine is needed due to holes in a virtual mem_map */
-extern void memmap_init_zone(unsigned long size, int nid, unsigned long
zone,
-unsigned long start_pfn);
+extern void memmap_init_zone(struct zone *zone);
# endif /* CONFIG_VIRTUAL_MEM_MAP */
# endif /* !__ASSEMBLY__ */
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index c8e68e92beb3..ccbda1a74c95 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -541,12 +541,14 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
return 0;
}
-void __meminit
-memmap_init_zone(unsigned long size, int nid, unsigned long zone,
-unsigned long start_pfn)
+void __meminit memmap_init_zone(struct zone *zone)
{
+ unsigned long size = zone->spanned_pages;
+ int nid = zone_to_nid(zone), zone_id = zone_idx(zone);
+ unsigned long start_pfn = zone->zone_start_pfn;
+
if (!vmem_map) {
- memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
+ memmap_init_range(size, nid, zone_id, start_pfn, start_pfn +
size,
MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
} else {
struct page *start;
@@ -556,7 +558,7 @@ memmap_init_zone(unsigned long size, int nid, unsigned long
zone,
args.start = start;
args.end = start + size;
args.nid = nid;
- args.zone = zone;
+ args.zone = zone_id;
efi_memmap_walk(virtual_memmap_init, );
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 69ebf75be91c..b2a46ffdaf0b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6292,16 +6292,16 @@ static inline u64 init_unavailable_range(unsigned long
spfn, unsigned long epfn,
}
#endif
-void __init __weak memmap_init_zone(unsigned long size, int nid,
- unsigned long zone,
- unsigned long zone_start_pfn)
+void __init __weak memmap_init_zone(struct zone *zone)
{
unsigned long start_pfn, end_pfn, hole_start_pfn = 0;
- unsigned long zone_end_pfn = zone_start_pfn + size;
+ int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone);
+ unsigned long zone_start_pfn = zone->zone_start_pfn;
+ unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages;
u64 pgcnt = 0;
- int i;
for_each_mem_pfn_range(i, nid, _pfn, _pfn, NULL) {
+ unsigned long size;
start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn);
end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn);
hole_start_pfn = clamp(hole_start_pfn, zone_start_pfn,
@@ -6309,13 +6309,13 @@ void __init __weak memmap_init_zone(unsigned long size,
int nid,
if (end_pfn > start_pfn) {
size = end_pfn - start_pfn;
- memmap_init_range(size, nid, zone, start_pfn,
zone_end_pfn,
+ memmap_init_range(size, nid, zone_id, start_pfn,
zone_end_pfn,
MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
}
if (hole_start_pfn < start_pfn)
pgcnt += init_unavailable_range(hole_start_pfn,
- start_pfn, zone, nid);
+ start_pfn, zone_id,
nid);
hole_start_pfn = end_pfn;
}
@@ -6328,11 +6328,11 @@ void __init __weak memmap_init_zone(unsigned long size,
int nid,
*/
if (hole_start_pfn < zone_end_pfn)
pgcnt += init_unavailable_range(hole_start_pfn, zone_end_pfn,
- zone, nid);
+ zone_id, nid);
if (pgcnt)
pr_info("%s: Zeroed struct page in unavailable ranges: %lld\n",
- zone_names[zone], pgcnt);
+ zone_names[zone_id], pgcnt);
}
static int zone_batchsize(struct zone *zone)
@@ -7039,7 +7039,7 @@ static void __init free_area_init_core(struct pglist_data
*pgdat)
set_pageblock_order();
[PATCH v3 3/4] mm: simplify parameter of setup_usemap()
Parameter 'zone' has got needed information, let's remove other
unnecessary parameters.
Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport
---
mm/page_alloc.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b2a46ffdaf0b..e0ce6fb6373b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6824,25 +6824,22 @@ static unsigned long __init usemap_size(unsigned long
zone_start_pfn, unsigned l
return usemapsize / 8;
}
-static void __ref setup_usemap(struct pglist_data *pgdat,
- struct zone *zone,
- unsigned long zone_start_pfn,
- unsigned long zonesize)
+static void __ref setup_usemap(struct zone *zone)
{
- unsigned long usemapsize = usemap_size(zone_start_pfn, zonesize);
+ unsigned long usemapsize = usemap_size(zone->zone_start_pfn,
+ zone->spanned_pages);
zone->pageblock_flags = NULL;
if (usemapsize) {
zone->pageblock_flags =
memblock_alloc_node(usemapsize, SMP_CACHE_BYTES,
- pgdat->node_id);
+ zone_to_nid(zone));
if (!zone->pageblock_flags)
panic("Failed to allocate %ld bytes for zone %s
pageblock flags on node %d\n",
- usemapsize, zone->name, pgdat->node_id);
+ usemapsize, zone->name, zone_to_nid(zone));
}
}
#else
-static inline void setup_usemap(struct pglist_data *pgdat, struct zone *zone,
- unsigned long zone_start_pfn, unsigned long
zonesize) {}
+static inline void setup_usemap(struct zone *zone) {}
#endif /* CONFIG_SPARSEMEM */
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
@@ -7037,7 +7034,7 @@ static void __init free_area_init_core(struct pglist_data
*pgdat)
continue;
set_pageblock_order();
- setup_usemap(pgdat, zone, zone_start_pfn, size);
+ setup_usemap(zone);
init_currently_empty_zone(zone, zone_start_pfn, size);
memmap_init_zone(zone);
}
--
2.17.2
[PATCH v3 0/4] mm: clean up names and parameters of memmap_init_xxxx functions
This patchset is correcting inappropriate function names of memmap_init_xxx, and simplify parameters of functions in the code flow when I tried to fix a regression bug in memmap defer init. These are taken from the v2 patchset, the bug fixing patch has bee sent alone and merged. So send the rest as v3. No any change comparing with v2, except of adding Mike's 'Reviewed-by' tag. V2 post is here: https://lore.kernel.org/linux-mm/20201220082754.6900-1-...@redhat.com/ Baoquan He (4): mm: rename memmap_init() and memmap_init_zone() mm: simplify parater of function memmap_init_zone() mm: simplify parameter of setup_usemap() mm: remove unneeded local variable in free_area_init_core arch/ia64/include/asm/pgtable.h | 3 +- arch/ia64/mm/init.c | 14 + include/linux/mm.h | 2 +- mm/memory_hotplug.c | 2 +- mm/page_alloc.c | 54 +++-- 5 files changed, 36 insertions(+), 39 deletions(-) -- 2.17.2
Re: uninitialized pmem struct pages
On Mon 04-01-21 17:30:48, David Hildenbrand wrote: > >> Let's assume this is indeed a reserved pfn in the altmap. What's the > >> actual address of the memmap? > > > > Not sure what exactly you are asking for but crash says > > crash> kmem -p 606 > > PAGE PHYSICAL MAPPING INDEX CNT FLAGS > > f8c600181800 60600 0 fc000 > > ^ this looks like it was somewhat initialized. All flags zero, nid/zone > set to -1 (wild guess) and thus the crash? weird Yes that made me scratch my head as well. > >> I do wonder what hosts pfn_to_page(PHYS_PFN(0x606)) - is it actually > >> part of the actual altmap (i.e. > 0x606) or maybe even self-hosted? > > > > I am not really familiar with the pmem so I would need more assistance > > here. I've tried this (shot into the dark): > > crash> struct page.pgmap f8c600181800 > > pgmap = 0xf8c600181808 > > That's weird. If the memmap is at f8c600181800, why should the pgmap > be at an offset of 8 bytes from there. The "pgmap" field is actually at > an offset of 8 bytes within the memmap ... I haven't noticed this is an offset into struct page. This is indeed weird because the structure is much larger than struct page. But maybe it reuses storage of several struct pages in a row. Or maybe it is not pgmap but something else that shares the offset in the structure. -- Michal Hocko SUSE Labs
Re: [PATCH v5 3/4] spmi: mediatek: Add support for MT6873/8192
On Wed, Dec 23, 2020 at 10:45 AM Hsin-Hsiung Wang
wrote:
>
> Add spmi support for MT6873/8192.
>
> Signed-off-by: Hsin-Hsiung Wang
> ---
> drivers/spmi/Kconfig | 9 +
> drivers/spmi/Makefile| 1 +
> drivers/spmi/spmi-mtk-pmif.c | 504 +++
> 3 files changed, 514 insertions(+)
> create mode 100644 drivers/spmi/spmi-mtk-pmif.c
>
> diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
> index a53bad541f1a..418848840999 100644
> --- a/drivers/spmi/Kconfig
> +++ b/drivers/spmi/Kconfig
> @@ -25,4 +25,13 @@ config SPMI_MSM_PMIC_ARB
> This is required for communicating with Qualcomm PMICs and
> other devices that have the SPMI interface.
>
> +config SPMI_MTK_PMIF
> + tristate "Mediatek SPMI Controller (PMIC Arbiter)"
> + help
> + If you say yes to this option, support will be included for the
> + built-in SPMI PMIC Arbiter interface on Mediatek family
> + processors.
> +
> + This is required for communicating with Mediatek PMICs and
> + other devices that have the SPMI interface.
> endif
> diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
> index 55a94cadeffe..91f303b96925 100644
> --- a/drivers/spmi/Makefile
> +++ b/drivers/spmi/Makefile
> @@ -5,3 +5,4 @@
> obj-$(CONFIG_SPMI) += spmi.o
>
> obj-$(CONFIG_SPMI_MSM_PMIC_ARB)+= spmi-pmic-arb.o
> +obj-$(CONFIG_SPMI_MTK_PMIF)+= spmi-mtk-pmif.o
> \ No newline at end of file
Newline at end of file please.
> diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
> new file mode 100644
> index ..711d3973800b
> --- /dev/null
> +++ b/drivers/spmi/spmi-mtk-pmif.c
> @@ -0,0 +1,504 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SWINF_IDLE 0x00
> +#define SWINF_WFVLDCLR 0x06
> +
> +#define GET_SWINF(x) (((x) >> 1) & 0x7)
> +
> +#define PMIF_CMD_REG_0 0
> +#define PMIF_CMD_REG 1
> +#define PMIF_CMD_EXT_REG 2
> +#define PMIF_CMD_EXT_REG_LONG 3
> +
> +#define PMIF_DELAY_US 10
> +#define PMIF_TIMEOUT(10 * 1000)
PMIF_TIMEOUT_US
> +
> +#define PMIF_CHAN_OFFSET 0x5
> +
> +#define SPMI_OP_ST_BUSY 1
> +
> +struct ch_reg {
> + u32 ch_sta;
> + u32 wdata;
> + u32 rdata;
> + u32 ch_send;
> + u32 ch_rdy;
> +};
> +
> +struct pmif {
> + void __iomem*base;
> + const u32 *regs;
> + void __iomem*spmimst_base;
> + const u32 *spmimst_regs;
> + u32 soc_chan;
> + int grpid;
Drop this, never used.
> + raw_spinlock_t lock;
> + struct clk *pmif_sys_ck;
> + struct clk *pmif_tmr_ck;
> + struct clk *spmimst_clk_mux;
> + struct ch_reg chan;
> +};
> +
> +enum pmif_regs {
> + PMIF_INIT_DONE,
> + PMIF_INF_EN,
> + PMIF_ARB_EN,
> + PMIF_CMDISSUE_EN,
> + PMIF_TIMER_CTRL,
> + PMIF_SPI_MODE_CTRL,
> + PMIF_IRQ_EVENT_EN_0,
> + PMIF_IRQ_FLAG_0,
> + PMIF_IRQ_CLR_0,
> + PMIF_IRQ_EVENT_EN_1,
> + PMIF_IRQ_FLAG_1,
> + PMIF_IRQ_CLR_1,
> + PMIF_IRQ_EVENT_EN_2,
> + PMIF_IRQ_FLAG_2,
> + PMIF_IRQ_CLR_2,
> + PMIF_IRQ_EVENT_EN_3,
> + PMIF_IRQ_FLAG_3,
> + PMIF_IRQ_CLR_3,
> + PMIF_IRQ_EVENT_EN_4,
> + PMIF_IRQ_FLAG_4,
> + PMIF_IRQ_CLR_4,
> + PMIF_WDT_EVENT_EN_0,
> + PMIF_WDT_FLAG_0,
> + PMIF_WDT_EVENT_EN_1,
> + PMIF_WDT_FLAG_1,
> + PMIF_SWINF_0_STA,
> + PMIF_SWINF_0_WDATA_31_0,
> + PMIF_SWINF_0_RDATA_31_0,
> + PMIF_SWINF_0_ACC,
> + PMIF_SWINF_0_VLD_CLR,
> + PMIF_SWINF_1_STA,
> + PMIF_SWINF_1_WDATA_31_0,
> + PMIF_SWINF_1_RDATA_31_0,
> + PMIF_SWINF_1_ACC,
> + PMIF_SWINF_1_VLD_CLR,
> + PMIF_SWINF_2_STA,
> + PMIF_SWINF_2_WDATA_31_0,
> + PMIF_SWINF_2_RDATA_31_0,
> + PMIF_SWINF_2_ACC,
> + PMIF_SWINF_2_VLD_CLR,
> + PMIF_SWINF_3_STA,
> + PMIF_SWINF_3_WDATA_31_0,
> + PMIF_SWINF_3_RDATA_31_0,
> + PMIF_SWINF_3_ACC,
> + PMIF_SWINF_3_VLD_CLR,
> +};
> +
> +static const u32 mt6873_regs[] = {
> + [PMIF_INIT_DONE] = 0x,
> + [PMIF_INF_EN] = 0x0024,
> + [PMIF_ARB_EN] = 0x0150,
> + [PMIF_CMDISSUE_EN] =0x03B4,
> + [PMIF_TIMER_CTRL] = 0x03E0,
> + [PMIF_SPI_MODE_CTRL] = 0x0400,
> + [PMIF_IRQ_EVENT_EN_0] = 0x0418,
> + [PMIF_IRQ_FLAG_0] = 0x0420,
> + [PMIF_IRQ_CLR_0] = 0x0424,
> + [PMIF_IRQ_EVENT_EN_1] = 0x0428,
> + [PMIF_IRQ_FLAG_1] = 0x0430,
> + [PMIF_IRQ_CLR_1] = 0x0434,
> + [PMIF_IRQ_EVENT_EN_2] = 0x0438,
> + [PMIF_IRQ_FLAG_2] = 0x0440,
> + [PMIF_IRQ_CLR_2] = 0x0444,
> + [PMIF_IRQ_EVENT_EN_3] = 0x0448,
> + [PMIF_IRQ_FLAG_3] =
Re: uninitialized pmem struct pages
On Mon 04-01-21 21:33:06, Dan Williams wrote: > On Mon, Jan 4, 2021 at 7:59 AM Michal Hocko wrote: [...] > > Not sure what exactly you are asking for but crash says > > crash> kmem -p 606 > > PAGE PHYSICAL MAPPING INDEX CNT FLAGS > > f8c600181800 60600 0 fc000 > > > > > I do wonder what hosts pfn_to_page(PHYS_PFN(0x606)) - is it actually > > > part of the actual altmap (i.e. > 0x606) or maybe even self-hosted? > > > > I am not really familiar with the pmem so I would need more assistance > > here. I've tried this (shot into the dark): > > crash> struct page.pgmap f8c600181800 > > pgmap = 0xf8c600181808 > > Does /proc/iomem show an active namespace in the range? Any tips how I dig that out from the crash dump? > You should be > able to skip ahead to the first pfn in that namespace to find the > first dev_pagemap. I would have expected pfn_to_online_page() to have > saved you here. This address range is section aligned. Well, the affected code in this case was end_pfn = min(start_pfn + nr_pages, zone_end_pfn(page_zone(pfn_to_page(start_pfn; where start_pfn was the first pfn of a memory section. This code was completely unaware of zone device or dev_pagemap like most others pfn walkers. It just wanted to get bounds for the zone but it stumbled over uninitialized zone/node. -- Michal Hocko SUSE Labs
Re: [PATCH mips-next 2/4] MIPS: vmlinux.lds.S: add ".rel.dyn" to DISCARDS
On Mon, Jan 4, 2021 at 4:21 AM Alexander Lobakin wrote: > > GCC somehow manages to place some of the symbols from main.c into > .rel.dyn section: > > mips-alpine-linux-musl-ld: warning: orphan section `.rel.dyn' > from `init/main.o' being placed in section `.rel.dyn' > > I couldn't catch up the exact symbol, but seems like it's harmless > to discard it from the final vmlinux as kernel doesn't use or > support dynamic relocations. > > Misc: sort DISCARDS section entries alphabetically. > > Signed-off-by: Alexander Lobakin > --- > arch/mips/kernel/vmlinux.lds.S | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S > index 83e27a181206..1c3c2e903062 100644 > --- a/arch/mips/kernel/vmlinux.lds.S > +++ b/arch/mips/kernel/vmlinux.lds.S > @@ -221,9 +221,10 @@ SECTIONS > /* ABI crap starts here */ > *(.MIPS.abiflags) > *(.MIPS.options) > + *(.eh_frame) > *(.options) > *(.pdr) > *(.reginfo) > - *(.eh_frame) > + *(.rel.dyn) > } > } > -- > 2.30.0 > > (I don't know why I am on the CC list since I know little about mips... Anyway, I know the LLD linker's behavior in case that was the intention... ) I think it'd be good to know the reason why these dynamic relocations are produced and fix the root cause. arch/x86/kernel/vmlinux.lds.S asserts no dynamic relocation: ASSERT(SIZEOF(.rela.dyn) == 0, "Unexpected run-time relocations (.rela) detected!")
[PATCH] drm/amdgpu:fix IH overflow on Cz
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2")
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR doesn't trigger another memory writeback.
So what can happen is that we end up processing the buffer overflow over and
over again because the bit is never cleared. Resulting in a random system
lockup because of an infinite loop in an interrupt handler.
Signed-off-by: Defang Bo
---
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 39 --
1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
index 1dca0cabc326..345987d45ff6 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
@@ -190,22 +190,33 @@ static u32 cz_ih_get_wptr(struct amdgpu_device *adev,
struct amdgpu_ih_ring *ih)
{
u32 wptr, tmp;
-
+
wptr = le32_to_cpu(*ih->wptr_cpu);
- if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
- wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
- /* When a ring buffer overflow happen start parsing interrupt
-* from the last not overwritten vector (wptr + 16). Hopefully
-* this should allow us to catchup.
-*/
- dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
- wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
- ih->rptr = (wptr + 16) & ih->ptr_mask;
- tmp = RREG32(mmIH_RB_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
- WREG32(mmIH_RB_CNTL, tmp);
- }
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = WREG32(mmIH_RB_CNTL, tmp);
+
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+
+
+ wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
+ /* When a ring buffer overflow happen start parsing interrupt
+* from the last not overwritten vector (wptr + 16). Hopefully
+* this should allow us to catchup.
+*/
+ dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
+ wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
+ ih->rptr = (wptr + 16) & ih->ptr_mask;
+ tmp = RREG32(mmIH_RB_CNTL);
+ tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
+ WREG32(mmIH_RB_CNTL, tmp);
+
+
+out:
return (wptr & ih->ptr_mask);
}
--
2.7.4
Re: [PATCH 2/2] spi: rpc-if: Remove CONFIG_PM_SLEEP ifdefery
Hi Pavel,
On Tue, Jan 5, 2021 at 12:40 AM Pavel Machek wrote:
> > > > > .name = "rpc-if-spi",
> > > > > - .pm = DEV_PM_OPS,
> > > > > + .pm = _spi_pm_ops,
> >
> > > > You're aware rpcif_spi_pm_ops is now always referenced and thus emitted,
> > > > increasing kernel size by 92 bytes if CONFIG_PM_SLEEP=n?
> > > > This may matter for RZ/A SoCs running from internal SRAM.
> >
> > > Hmm didn't realise this would be an issue on RZ/A.
> >
> > > Mark, could you please drop this patch from your branch.
> >
> > Please send an incremental patch with an appropriate changelog.
>
> Let's fix this properly. I'm pretty sure we have some macros that can
> solve this without re-introducing the ifdefs...
There's pm_ptr(), but it uses CONFIG_PM as a selector, not CONFIG_PM_SLEEP.
> (Besides... 92 bytes. How big is kernel these days? 4MB? More? How
> much SRAM do you have?)
92 bytes is indeed not much (on 64-bit it would be doubled).
Still, it's good to make people think about innocent looking changes,
once in a while.
RZ/A1H and RZ/A1M have 10 resp. 5 MiB of SRAM.
RZ/A2 has 4 MiB SRAM, which is sufficient to run Linux when used with
XIP (requires a one-line Kconfig change rmk has been vetoing for years).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH RFC v4 1/1] scsi: ufs: Fix ufs power down/on specs violation
On 5/01/21 9:28 am, Can Guo wrote: > On 2021-01-05 15:16, Adrian Hunter wrote: >> On 4/01/21 8:55 pm, Bjorn Andersson wrote: >>> On Mon 04 Jan 03:15 CST 2021, Adrian Hunter wrote: >>> On 22/12/20 3:49 pm, Ziqi Chen wrote: > As per specs, e.g, JESD220E chapter 7.2, while powering > off/on the ufs device, RST_N signal and REF_CLK signal > should be between VSS(Ground) and VCCQ/VCCQ2. > > To flexibly control device reset line, refactor the function > ufschd_vops_device_reset(sturct ufs_hba *hba) to ufshcd_ > vops_device_reset(sturct ufs_hba *hba, bool asserted). The > new parameter "bool asserted" is used to separate device reset > line pulling down from pulling up. This patch assumes the power is controlled by voltage regulators, but for us it is controlled by firmware (ACPI), so it is not correct to change RST_n for all host controllers as you are doing. Also we might need to use a firmware interface for device reset, in which case the 'asserted' value doe not make sense. >>> >>> Are you saying that the entire flip-flop-the-reset is a single firmware >>> operation in your case? >> >> Yes >> >>> If you look at the Mediatek driver, the >>> implementation of ufs_mtk_device_reset_ctrl() is a jump to firmware. >>> >>> >>> But perhaps "asserted" isn't the appropriate English word for saying >>> "the reset is in the resetting state"? >>> >>> I just wanted to avoid the use of "high"/"lo" as if you look at the >>> Mediatek code they pass the expected line-level to the firmware, while >>> in the Qualcomm code we pass the logical state to the GPIO code which is >>> setup up as "active low" and thereby flip the meaning before hitting the >>> pad. >>> Can we leave the device reset callback alone, and instead introduce a new variant operation for setting RST_n to match voltage regulator power changes? >>> >>> Wouldn't this new function just have to look like the proposed patches? >>> In which case for existing platforms we'd have both? >>> >>> How would you implement this, or would you simply skip implementing >>> this? >> >> Functionally, doing a device reset is not the same as adjusting signal >> levels to meet power up/off ramp requirements. However, the issue is that >> we do not use regulators, so the power is not necessarily being changed at >> those points, and we definitely do not want to reset instead of entering >> DeepSleep for example. >> >> Off the top of my head, I imagine something like a callback called >> ufshcd_vops_prepare_power_ramp(hba, bool on) which is called only if >> hba->vreg_info->vcc is not NULL. > > Hi Adrian, > > I don't see you have the vops device_reset() implemented anywhere in > current code base, how is this change impacting you? Do I miss anything > or are you planning to push a change which implements device_reset() soon? At some point, yes.
Re: [External] Re: [PATCH 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page
On Tue, Jan 05, 2021 at 03:10:35PM +0800, Muchun Song wrote:
> On Tue, Jan 5, 2021 at 2:38 PM HORIGUCHI NAOYA(堀口 直也)
> wrote:
> >
> > On Mon, Jan 04, 2021 at 02:58:41PM +0800, Muchun Song wrote:
> > > When dissolve_free_huge_page() races with __free_huge_page(), we can
> > > do a retry. Because the race window is small.
> > >
> > > Signed-off-by: Muchun Song
> > > ---
> > > mm/hugetlb.c | 16 +++-
> > > 1 file changed, 11 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > index 72608008f8b4..db00ae375d2a 100644
> > > --- a/mm/hugetlb.c
> > > +++ b/mm/hugetlb.c
> > > @@ -1763,10 +1763,11 @@ static int free_pool_huge_page(struct hstate *h,
> > > nodemask_t *nodes_allowed,
> > > * nothing for in-use hugepages and non-hugepages.
> > > * This function returns values like below:
> > > *
> > > - * -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
> > > - * (allocated or reserved.)
> > > - * 0: successfully dissolved free hugepages or the page is not a
> > > - * hugepage (considered as already dissolved)
> > > + * -EAGAIN: race with __free_huge_page() and can do a retry
> > > + * -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
> > > + * (allocated or reserved.)
> > > + * 0: successfully dissolved free hugepages or the page is not a
> > > + * hugepage (considered as already dissolved)
> > > */
> > > int dissolve_free_huge_page(struct page *page)
> > > {
> > > @@ -1815,8 +1816,10 @@ int dissolve_free_huge_page(struct page *page)
> > >* We should make sure that the page is already on the free
> > > list
> > >* when it is dissolved.
> > >*/
> > > - if (unlikely(!PageHugeFreed(head)))
> > > + if (unlikely(!PageHugeFreed(head))) {
> > > + rc = -EAGAIN;
> > > goto out;
> > > + }
> >
> > If dissolve_free_huge_page() races with __free_huge_page() and we detect
> > it with this check, the hugepage is expected to be freed or dissolved by
> > __free_huge_page(), so is it enough just to return with rc = 0 without
> > retrying?
>
> The dissolve_free_huge_page() aims to free the page to the buddy
> allocator not the hugepage pool. So it is not enough just to return 0,
> right? Or did you mean that we set the page temporary here and
> let the __free_huge_page do the freeing later for us? Thanks.
Ah, OK. You're right.
Thank you for the answer (and finding/fixing a few bugs).
- Naoya
kerneldoc warnings since commit 538fc2ee870a3 ("rcu: Introduce kfree_rcu() single-argument macro")
Dear Uladzislau,
in commit 538fc2ee870a3 ("rcu: Introduce kfree_rcu() single-argument
macro"), you have refactored the kfree_rcu macro.
Since then, make htmldocs warns:
./include/linux/rcupdate.h:882: warning: Excess function parameter
'ptr' description in 'kfree_rcu'
./include/linux/rcupdate.h:882: warning: Excess function parameter
'rhf' description in 'kfree_rcu'
As you deleted the two arguments in the macro definition, kerneldoc
cannot resolve the argument names in the macro's kerneldoc
documentation anymore and warns about that.
Probably, it is best to just turn the formal kerneldoc references to
the two arguments, which are not used in the macro definition anymore,
simply into two informal references in the documentation.
Best regards,
Lukas
Re: [PATCH] mm/page_alloc: remove the static for local variable node_order
On Mon 04-01-21 15:23:57, Andrew Morton wrote: > On Wed, 30 Dec 2020 12:42:33 + Matthew Wilcox wrote: > > > On Wed, Dec 30, 2020 at 07:40:14PM +0800, Hui Su wrote: > > > local variable node_order do not need the static here. > > > > It bloody well does. It can be up to 2^10 entries on x86 (and larger > > on others) That's 4kB which you've now moved onto the stack. > > That being said, could we kmalloc the scratch area in > __build_all_zonelists()? And maybe remove that static spinlock? I am not sure we can (e.g. early init code) but even if we could, what would be an advantage. This code is called very seldom with a very shallow stacks so using the stack allocation sounds like the easiest thing to do. > (what blocks node and cpu hotplug in there??) Memory hotplug is excluded by the caller when it matters (e.g. no locking for the early init). -- Michal Hocko SUSE Labs
Re: [PATCH RFC v4 1/1] scsi: ufs: Fix ufs power down/on specs violation
On 2021-01-05 15:16, Adrian Hunter wrote: On 4/01/21 8:55 pm, Bjorn Andersson wrote: On Mon 04 Jan 03:15 CST 2021, Adrian Hunter wrote: On 22/12/20 3:49 pm, Ziqi Chen wrote: As per specs, e.g, JESD220E chapter 7.2, while powering off/on the ufs device, RST_N signal and REF_CLK signal should be between VSS(Ground) and VCCQ/VCCQ2. To flexibly control device reset line, refactor the function ufschd_vops_device_reset(sturct ufs_hba *hba) to ufshcd_ vops_device_reset(sturct ufs_hba *hba, bool asserted). The new parameter "bool asserted" is used to separate device reset line pulling down from pulling up. This patch assumes the power is controlled by voltage regulators, but for us it is controlled by firmware (ACPI), so it is not correct to change RST_n for all host controllers as you are doing. Also we might need to use a firmware interface for device reset, in which case the 'asserted' value doe not make sense. Are you saying that the entire flip-flop-the-reset is a single firmware operation in your case? Yes If you look at the Mediatek driver, the implementation of ufs_mtk_device_reset_ctrl() is a jump to firmware. But perhaps "asserted" isn't the appropriate English word for saying "the reset is in the resetting state"? I just wanted to avoid the use of "high"/"lo" as if you look at the Mediatek code they pass the expected line-level to the firmware, while in the Qualcomm code we pass the logical state to the GPIO code which is setup up as "active low" and thereby flip the meaning before hitting the pad. Can we leave the device reset callback alone, and instead introduce a new variant operation for setting RST_n to match voltage regulator power changes? Wouldn't this new function just have to look like the proposed patches? In which case for existing platforms we'd have both? How would you implement this, or would you simply skip implementing this? Functionally, doing a device reset is not the same as adjusting signal levels to meet power up/off ramp requirements. However, the issue is that we do not use regulators, so the power is not necessarily being changed at those points, and we definitely do not want to reset instead of entering DeepSleep for example. Off the top of my head, I imagine something like a callback called ufshcd_vops_prepare_power_ramp(hba, bool on) which is called only if hba->vreg_info->vcc is not NULL. Hi Adrian, I don't see you have the vops device_reset() implemented anywhere in current code base, how is this change impacting you? Do I miss anything or are you planning to push a change which implements device_reset() soon? Thanks, Can Guo.
Re: Possible regression in cpuacct.stats system time
On 04/01/21 22:24, Nitesh Narayan Lal wrote: Hi, Last year I reported an issue of "suspicious RCU usage" [1] with the debug kernel which was fixed with the patch: 87fa7f3e98 "x86/kvm: Move context tracking where it belongs" Recently I have come across a possible regression because of this patch in the cpuacct.stats system time. With the latest upstream kernel (5.11-rc2) when we set up a VM and start observing the system time value from cpuacct.stat then it is significantly higher than value reported with the kernel that doesn't have the previously mentioned patch. FWIU the reason behind this increase is the moving of guest_exit_irqoff() to its proper location (near vmexit). This leads to the accounting of instructions that were previously accounted into the guest context as a part of the system time. IMO this should be an expected behavior after the previously mentioned change. Is that a right conclusion or I am missing something here? Yes it's expected and I think it's more precise, since this is host overhead rather than guest operation . Another question that I have is about the patch d7a08882a0 "KVM: x86: Unconditionally enable irqs in guest context" considering we are enabling irqs early now in the code path, do we still need this patch? No, we don't. Since the code is a bit simpler without it, feel free to send a revert. Thanks, Paolo [1] https://lore.kernel.org/lkml/ece36eb1-253a-8ec6-c183-309c10bb3...@redhat.com/ -- Thanks Nitesh
Re: i2c: mediatek: Fix apdma and i2c hand-shake timeout
On Mon, 2021-01-04 at 19:32 +0100, Wolfram Sang wrote:
> On Mon, Jan 04, 2021 at 07:29:59PM +0100, Wolfram Sang wrote:
> > On Thu, Dec 24, 2020 at 08:26:07PM +0800, qii.w...@mediatek.com wrote:
> > > From: Qii Wang
> > >
> > > With the apdma remove hand-shake signal, it requirs special
> > > operation timing to reset i2c manually, otherwise the interrupt
> > > will not be triggered, i2c transmission will be timeout.
> > >
> > > Signed-off-by: Qii Wang
> >
> > Applied to for-current, thanks!
>
> Any Fixes:-Tag we could add?
>
Could you help me add:
Fixes: 8426fe70cfa4("i2c: mediatek: Add apdma sync in i2c driver")
Thanks
Re: [PATCH] tee: optee: replace might_sleep with cond_resched
On Tue, Jan 5, 2021 at 6:42 AM Sumit Garg wrote:
>
> On Fri, 25 Sept 2020 at 12:29, Jens Wiklander via OP-TEE
> wrote:
> >
> > On Fri, Sep 18, 2020 at 7:45 PM Rouven Czerwinski
> > wrote:
> > >
> > > On Kernels with CONFIG_PREEMPT_NONE might_sleep() is not enough to force
> > > rescheduling, replace it with a resched check and cond_resched. Fixes
> > > the following stall:
> > >
> > > [ 572.945146] rcu: INFO: rcu_sched self-detected stall on CPU
> > > [ 572.949275] rcu: 0-: (2099 ticks this GP)
> > > idle=572/1/0x4002 softirq=7412/7412 fqs=974
> > > [ 572.957964] (t=2100 jiffies g=10393 q=21)
> > > [ 572.962054] NMI backtrace for cpu 0
> > > [ 572.965540] CPU: 0 PID: 165 Comm: xtest Not tainted 5.8.7 #1
> > > [ 572.971188] Hardware name: STM32 (Device Tree Support)
> > > [ 572.976354] [] (unwind_backtrace) from []
> > > (show_stack+0x10/0x14)
> > > [ 572.984080] [] (show_stack) from []
> > > (dump_stack+0xc4/0xd8)
> > > [ 572.991300] [] (dump_stack) from []
> > > (nmi_cpu_backtrace+0x90/0xc4)
> > > [ 572.999130] [] (nmi_cpu_backtrace) from []
> > > (nmi_trigger_cpumask_backtrace+0xec/0x130)
> > > [ 573.008706] [] (nmi_trigger_cpumask_backtrace) from
> > > [] (rcu_dump_cpu_stacks+0xe8/0x110)
> > > [ 573.018453] [] (rcu_dump_cpu_stacks) from []
> > > (rcu_sched_clock_irq+0x7fc/0xa88)
> > > [ 573.027416] [] (rcu_sched_clock_irq) from []
> > > (update_process_times+0x30/0x8c)
> > > [ 573.036291] [] (update_process_times) from []
> > > (tick_sched_timer+0x4c/0xa8)
> > > [ 573.044905] [] (tick_sched_timer) from []
> > > (__hrtimer_run_queues+0x174/0x358)
> > > [ 573.053696] [] (__hrtimer_run_queues) from []
> > > (hrtimer_interrupt+0x118/0x2bc)
> > > [ 573.062573] [] (hrtimer_interrupt) from []
> > > (arch_timer_handler_virt+0x28/0x30)
> > > [ 573.071536] [] (arch_timer_handler_virt) from []
> > > (handle_percpu_devid_irq+0x8c/0x240)
> > > [ 573.081109] [] (handle_percpu_devid_irq) from []
> > > (generic_handle_irq+0x34/0x44)
> > > [ 573.090156] [] (generic_handle_irq) from []
> > > (__handle_domain_irq+0x5c/0xb0)
> > > [ 573.098857] [] (__handle_domain_irq) from []
> > > (gic_handle_irq+0x4c/0x90)
> > > [ 573.107209] [] (gic_handle_irq) from []
> > > (__irq_svc+0x6c/0x90)
> > > [ 573.114682] Exception stack(0xd90dfcf8 to 0xd90dfd40)
> > > [ 573.119732] fce0:
> > >0004
> > > [ 573.127917] fd00:
> > > d93493cc
> > > [ 573.136098] fd20: d2bc39c0 be926998 d90dfd58 d90dfd48 c09f3384
> > > c01151f0 400d0013
> > > [ 573.144281] [] (__irq_svc) from []
> > > (__arm_smccc_smc+0x10/0x20)
> > > [ 573.151854] [] (__arm_smccc_smc) from []
> > > (optee_smccc_smc+0x3c/0x44)
> > > [ 573.159948] [] (optee_smccc_smc) from []
> > > (optee_do_call_with_arg+0xb8/0x154)
> > > [ 573.168735] [] (optee_do_call_with_arg) from []
> > > (optee_invoke_func+0x110/0x190)
> > > [ 573.177786] [] (optee_invoke_func) from []
> > > (tee_ioctl+0x10b8/0x11c0)
> > > [ 573.185879] [] (tee_ioctl) from []
> > > (ksys_ioctl+0xe0/0xa4c)
> > > [ 573.193101] [] (ksys_ioctl) from []
> > > (ret_fast_syscall+0x0/0x54)
> > > [ 573.200750] Exception stack(0xd90dffa8 to 0xd90dfff0)
> > > [ 573.205803] ffa0: be926bf4 be926a78 0003
> > > 8010a403 be926908 004e3cf8
> > > [ 573.213987] ffc0: be926bf4 be926a78 0036 be926908
> > > be926918 be9269b0 bffdf0f8
> > > [ 573.222162] ffe0: b6d76fb0 be9268fc b6d66621 b6c7e0d8
> > >
> > > seen on STM32 DK2.
> > >
> > > Signed-off-by: Rouven Czerwinski
> > > ---
> > > drivers/tee/optee/call.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
> > > index 20b6fd7383c5..83b73b1d52f0 100644
> > > --- a/drivers/tee/optee/call.c
> > > +++ b/drivers/tee/optee/call.c
> > > @@ -8,6 +8,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -148,7 +149,8 @@ u32 optee_do_call_with_arg(struct tee_context *ctx,
> > > phys_addr_t parg)
> > > */
> > > optee_cq_wait_for_completion(>call_queue,
> > > );
> > > } else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) {
> > > - might_sleep();
> > > + if(need_resched())
> > > + cond_resched();
> >
> > This looks OK to me. But I'd prefer if someone else could confirm this too.
> >
>
> Tested-by: Sumit Garg
Thanks Sumit.
Rouven, would you mind making a V2 with the changes requested by Lucas
in another mail in this thread?
Cheers,
Jens
>
> -Sumit
>
> > Thanks,
> > Jens
> >
> > > param.a0 = res.a0;
> > > param.a1 = res.a1;
> > >
[PATCH v3 1/6] iio: hid-sensor-accel-3d: Add timestamp channel for gravity sensor
The accel_3d sensor already has a timestamp channel, this patch just
replicate that for gravity sensor.
Signed-off-by: Ye Xiang
---
drivers/iio/accel/hid-sensor-accel-3d.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c
b/drivers/iio/accel/hid-sensor-accel-3d.c
index 589b7d8a36f2..7cd3cd81b1a7 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -23,6 +23,7 @@ enum accel_3d_channel {
ACCEL_3D_CHANNEL_MAX,
};
+#define CHANNEL_SCAN_INDEX_TIMESTAMP ACCEL_3D_CHANNEL_MAX
struct accel_3d_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
@@ -82,7 +83,7 @@ static const struct iio_chan_spec accel_3d_channels[] = {
BIT(IIO_CHAN_INFO_HYSTERESIS),
.scan_index = CHANNEL_SCAN_INDEX_Z,
},
- IIO_CHAN_SOFT_TIMESTAMP(3)
+ IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
/* Channel definitions */
@@ -117,7 +118,8 @@ static const struct iio_chan_spec gravity_channels[] = {
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
.scan_index = CHANNEL_SCAN_INDEX_Z,
- }
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP),
};
/* Adjust channel real bits based on report descriptor */
--
2.17.1
[PATCH v3 6/6] iio: hid-sensor-rotation: Add timestamp channel
Each sample has a timestamp field with this change. This timestamp may
be from the sensor hub when present or local kernel timestamp. And the
unit of timestamp is nanosecond.
Signed-off-by: Ye Xiang
---
drivers/iio/orientation/hid-sensor-rotation.c | 46 +++
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/iio/orientation/hid-sensor-rotation.c
b/drivers/iio/orientation/hid-sensor-rotation.c
index 665ccf3673cc..b0245b3b7ffc 100644
--- a/drivers/iio/orientation/hid-sensor-rotation.c
+++ b/drivers/iio/orientation/hid-sensor-rotation.c
@@ -20,11 +20,15 @@ struct dev_rot_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info quaternion;
- u32 sampled_vals[4];
+ struct {
+ u32 sampled_vals[4] __aligned(16);
+ u64 timestamp __aligned(8);
+ } scan;
int scale_pre_decml;
int scale_post_decml;
int scale_precision;
int value_offset;
+ s64 timestamp;
};
static const u32 rotation_sensitivity_addresses[] = {
@@ -42,8 +46,10 @@ static const struct iio_chan_spec dev_rot_channels[] = {
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_OFFSET) |
BIT(IIO_CHAN_INFO_SCALE) |
- BIT(IIO_CHAN_INFO_HYSTERESIS)
- }
+ BIT(IIO_CHAN_INFO_HYSTERESIS),
+ .scan_index = 0
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(1)
};
/* Adjust channel real bits based on report descriptor */
@@ -75,7 +81,7 @@ static int dev_rot_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_RAW:
if (size >= 4) {
for (i = 0; i < 4; ++i)
- vals[i] = rot_state->sampled_vals[i];
+ vals[i] = rot_state->scan.sampled_vals[i];
ret_type = IIO_VAL_INT_MULTIPLE;
*val_len = 4;
} else
@@ -137,15 +143,6 @@ static const struct iio_info dev_rot_info = {
.write_raw = _rot_write_raw,
};
-/* Function to push data to buffer */
-static void hid_sensor_push_data(struct iio_dev *indio_dev, u8 *data, int len)
-{
- dev_dbg(_dev->dev, "hid_sensor_push_data >>\n");
- iio_push_to_buffers(indio_dev, (u8 *)data);
- dev_dbg(_dev->dev, "hid_sensor_push_data <<\n");
-
-}
-
/* Callback handler to send event after all samples are received and captured
*/
static int dev_rot_proc_event(struct hid_sensor_hub_device *hsdev,
unsigned usage_id,
@@ -155,10 +152,15 @@ static int dev_rot_proc_event(struct
hid_sensor_hub_device *hsdev,
struct dev_rot_state *rot_state = iio_priv(indio_dev);
dev_dbg(_dev->dev, "dev_rot_proc_event\n");
- if (atomic_read(_state->common_attributes.data_ready))
- hid_sensor_push_data(indio_dev,
- (u8 *)rot_state->sampled_vals,
- sizeof(rot_state->sampled_vals));
+ if (atomic_read(_state->common_attributes.data_ready)) {
+ if (!rot_state->timestamp)
+ rot_state->timestamp = iio_get_time_ns(indio_dev);
+
+ iio_push_to_buffers_with_timestamp(indio_dev, _state->scan,
+ rot_state->timestamp);
+
+ rot_state->timestamp = 0;
+ }
return 0;
}
@@ -173,10 +175,14 @@ static int dev_rot_capture_sample(struct
hid_sensor_hub_device *hsdev,
struct dev_rot_state *rot_state = iio_priv(indio_dev);
if (usage_id == HID_USAGE_SENSOR_ORIENT_QUATERNION) {
- memcpy(rot_state->sampled_vals, raw_data,
- sizeof(rot_state->sampled_vals));
+ memcpy(_state->scan.sampled_vals, raw_data,
+ sizeof(rot_state->scan.sampled_vals));
+
dev_dbg(_dev->dev, "Recd Quat len:%zu::%zu\n", raw_len,
- sizeof(rot_state->sampled_vals));
+ sizeof(rot_state->scan.sampled_vals));
+ } else if (usage_id == HID_USAGE_SENSOR_TIME_TIMESTAMP) {
+ rot_state->timestamp =
hid_sensor_convert_timestamp(_state->common_attributes,
+ *(s64
*)raw_data);
}
return 0;
--
2.17.1
[PATCH v3 2/6] iio: hid-sensor-gyro-3d: Add timestamp channel
Each sample has a timestamp field with this change. This timestamp may
be from the sensor hub when present or local kernel timestamp. And the
unit of timestamp is nanosecond.
Signed-off-by: Ye Xiang
---
drivers/iio/gyro/hid-sensor-gyro-3d.c | 40 ---
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c
b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index c817d91b3b51..37c7ac0ad32b 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -23,15 +23,20 @@ enum gyro_3d_channel {
GYRO_3D_CHANNEL_MAX,
};
+#define CHANNEL_SCAN_INDEX_TIMESTAMP GYRO_3D_CHANNEL_MAX
struct gyro_3d_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info gyro[GYRO_3D_CHANNEL_MAX];
- u32 gyro_val[GYRO_3D_CHANNEL_MAX];
+ struct {
+ u32 gyro_val[GYRO_3D_CHANNEL_MAX];
+ u64 timestamp __aligned(8);
+ } scan;
int scale_pre_decml;
int scale_post_decml;
int scale_precision;
int value_offset;
+ s64 timestamp;
};
static const u32 gyro_3d_addresses[GYRO_3D_CHANNEL_MAX] = {
@@ -79,7 +84,8 @@ static const struct iio_chan_spec gyro_3d_channels[] = {
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
.scan_index = CHANNEL_SCAN_INDEX_Z,
- }
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
/* Adjust channel real bits based on report descriptor */
@@ -185,14 +191,6 @@ static const struct iio_info gyro_3d_info = {
.write_raw = _3d_write_raw,
};
-/* Function to push data to buffer */
-static void hid_sensor_push_data(struct iio_dev *indio_dev, const void *data,
- int len)
-{
- dev_dbg(_dev->dev, "hid_sensor_push_data\n");
- iio_push_to_buffers(indio_dev, data);
-}
-
/* Callback handler to send event after all samples are received and captured
*/
static int gyro_3d_proc_event(struct hid_sensor_hub_device *hsdev,
unsigned usage_id,
@@ -202,10 +200,15 @@ static int gyro_3d_proc_event(struct
hid_sensor_hub_device *hsdev,
struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
dev_dbg(_dev->dev, "gyro_3d_proc_event\n");
- if (atomic_read(_state->common_attributes.data_ready))
- hid_sensor_push_data(indio_dev,
- gyro_state->gyro_val,
- sizeof(gyro_state->gyro_val));
+ if (atomic_read(_state->common_attributes.data_ready)) {
+ if (!gyro_state->timestamp)
+ gyro_state->timestamp = iio_get_time_ns(indio_dev);
+
+ iio_push_to_buffers_with_timestamp(indio_dev, _state->scan,
+ gyro_state->timestamp);
+
+ gyro_state->timestamp = 0;
+ }
return 0;
}
@@ -226,10 +229,15 @@ static int gyro_3d_capture_sample(struct
hid_sensor_hub_device *hsdev,
case HID_USAGE_SENSOR_ANGL_VELOCITY_Y_AXIS:
case HID_USAGE_SENSOR_ANGL_VELOCITY_Z_AXIS:
offset = usage_id - HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS;
- gyro_state->gyro_val[CHANNEL_SCAN_INDEX_X + offset] =
- *(u32 *)raw_data;
+ gyro_state->scan.gyro_val[CHANNEL_SCAN_INDEX_X + offset] =
+ *(u32 *)raw_data;
ret = 0;
break;
+ case HID_USAGE_SENSOR_TIME_TIMESTAMP:
+ gyro_state->timestamp =
+
hid_sensor_convert_timestamp(_state->common_attributes,
+*(s64 *)raw_data);
+ break;
default:
break;
}
--
2.17.1
[PATCH v3 3/6] iio: hid-sensor-als: Add timestamp channel
Each sample has a timestamp field with this change. This timestamp may
be from the sensor hub when present or local kernel timestamp. And the
unit of timestamp is nanosecond.
Signed-off-by: Ye Xiang
---
drivers/iio/light/hid-sensor-als.c | 39 ++
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c
b/drivers/iio/light/hid-sensor-als.c
index 5460a744dbd0..afcdb424bfb8 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -22,15 +22,21 @@ enum {
CHANNEL_SCAN_INDEX_MAX
};
+#define CHANNEL_SCAN_INDEX_TIMESTAMP CHANNEL_SCAN_INDEX_MAX
+
struct als_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info als_illum;
- u32 illum[CHANNEL_SCAN_INDEX_MAX];
+ struct {
+ u32 illum[CHANNEL_SCAN_INDEX_MAX];
+ u64 timestamp __aligned(8);
+ } scan;
int scale_pre_decml;
int scale_post_decml;
int scale_precision;
int value_offset;
+ s64 timestamp;
};
static const u32 als_sensitivity_addresses[] = {
@@ -59,7 +65,8 @@ static const struct iio_chan_spec als_channels[] = {
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
.scan_index = CHANNEL_SCAN_INDEX_ILLUM,
- }
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
/* Adjust channel real bits based on report descriptor */
@@ -173,14 +180,6 @@ static const struct iio_info als_info = {
.write_raw = _write_raw,
};
-/* Function to push data to buffer */
-static void hid_sensor_push_data(struct iio_dev *indio_dev, const void *data,
- int len)
-{
- dev_dbg(_dev->dev, "hid_sensor_push_data\n");
- iio_push_to_buffers(indio_dev, data);
-}
-
/* Callback handler to send event after all samples are received and captured
*/
static int als_proc_event(struct hid_sensor_hub_device *hsdev,
unsigned usage_id,
@@ -190,10 +189,14 @@ static int als_proc_event(struct hid_sensor_hub_device
*hsdev,
struct als_state *als_state = iio_priv(indio_dev);
dev_dbg(_dev->dev, "als_proc_event\n");
- if (atomic_read(_state->common_attributes.data_ready))
- hid_sensor_push_data(indio_dev,
- _state->illum,
- sizeof(als_state->illum));
+ if (atomic_read(_state->common_attributes.data_ready)) {
+ if (!als_state->timestamp)
+ als_state->timestamp = iio_get_time_ns(indio_dev);
+
+ iio_push_to_buffers_with_timestamp(indio_dev, _state->scan,
+ als_state->timestamp);
+ als_state->timestamp = 0;
+ }
return 0;
}
@@ -211,10 +214,14 @@ static int als_capture_sample(struct
hid_sensor_hub_device *hsdev,
switch (usage_id) {
case HID_USAGE_SENSOR_LIGHT_ILLUM:
- als_state->illum[CHANNEL_SCAN_INDEX_INTENSITY] = sample_data;
- als_state->illum[CHANNEL_SCAN_INDEX_ILLUM] = sample_data;
+ als_state->scan.illum[CHANNEL_SCAN_INDEX_INTENSITY] =
sample_data;
+ als_state->scan.illum[CHANNEL_SCAN_INDEX_ILLUM] = sample_data;
ret = 0;
break;
+ case HID_USAGE_SENSOR_TIME_TIMESTAMP:
+ als_state->timestamp =
hid_sensor_convert_timestamp(_state->common_attributes,
+ *(s64
*)raw_data);
+ break;
default:
break;
}
--
2.17.1
[PATCH v3 5/6] iio: hid-sensor-incl-3d: Add timestamp channel
Each sample has a timestamp field with this change. This timestamp may
be from the sensor hub when present or local kernel timestamp. And the
unit of timestamp is nanosecond.
Signed-off-by: Ye Xiang
---
drivers/iio/orientation/hid-sensor-incl-3d.c | 43
1 file changed, 27 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c
b/drivers/iio/orientation/hid-sensor-incl-3d.c
index df2fe91e8117..3baa52fbb426 100644
--- a/drivers/iio/orientation/hid-sensor-incl-3d.c
+++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
@@ -24,15 +24,21 @@ enum incl_3d_channel {
INCLI_3D_CHANNEL_MAX,
};
+#define CHANNEL_SCAN_INDEX_TIMESTAMP INCLI_3D_CHANNEL_MAX
+
struct incl_3d_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info incl[INCLI_3D_CHANNEL_MAX];
- u32 incl_val[INCLI_3D_CHANNEL_MAX];
+ struct {
+ u32 incl_val[INCLI_3D_CHANNEL_MAX];
+ u64 timestamp __aligned(8);
+ } scan;
int scale_pre_decml;
int scale_post_decml;
int scale_precision;
int value_offset;
+ s64 timestamp;
};
static const u32 incl_3d_addresses[INCLI_3D_CHANNEL_MAX] = {
@@ -81,7 +87,8 @@ static const struct iio_chan_spec incl_3d_channels[] = {
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
.scan_index = CHANNEL_SCAN_INDEX_Z,
- }
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP),
};
/* Adjust channel real bits based on report descriptor */
@@ -186,13 +193,6 @@ static const struct iio_info incl_3d_info = {
.write_raw = _3d_write_raw,
};
-/* Function to push data to buffer */
-static void hid_sensor_push_data(struct iio_dev *indio_dev, u8 *data, int len)
-{
- dev_dbg(_dev->dev, "hid_sensor_push_data\n");
- iio_push_to_buffers(indio_dev, (u8 *)data);
-}
-
/* Callback handler to send event after all samples are received and captured
*/
static int incl_3d_proc_event(struct hid_sensor_hub_device *hsdev,
unsigned usage_id,
@@ -202,10 +202,16 @@ static int incl_3d_proc_event(struct
hid_sensor_hub_device *hsdev,
struct incl_3d_state *incl_state = iio_priv(indio_dev);
dev_dbg(_dev->dev, "incl_3d_proc_event\n");
- if (atomic_read(_state->common_attributes.data_ready))
- hid_sensor_push_data(indio_dev,
- (u8 *)incl_state->incl_val,
- sizeof(incl_state->incl_val));
+ if (atomic_read(_state->common_attributes.data_ready)) {
+ if (!incl_state->timestamp)
+ incl_state->timestamp = iio_get_time_ns(indio_dev);
+
+ iio_push_to_buffers_with_timestamp(indio_dev,
+ _state->scan,
+ incl_state->timestamp);
+
+ incl_state->timestamp = 0;
+ }
return 0;
}
@@ -222,13 +228,18 @@ static int incl_3d_capture_sample(struct
hid_sensor_hub_device *hsdev,
switch (usage_id) {
case HID_USAGE_SENSOR_ORIENT_TILT_X:
- incl_state->incl_val[CHANNEL_SCAN_INDEX_X] = *(u32 *)raw_data;
+ incl_state->scan.incl_val[CHANNEL_SCAN_INDEX_X] = *(u32
*)raw_data;
break;
case HID_USAGE_SENSOR_ORIENT_TILT_Y:
- incl_state->incl_val[CHANNEL_SCAN_INDEX_Y] = *(u32 *)raw_data;
+ incl_state->scan.incl_val[CHANNEL_SCAN_INDEX_Y] = *(u32
*)raw_data;
break;
case HID_USAGE_SENSOR_ORIENT_TILT_Z:
- incl_state->incl_val[CHANNEL_SCAN_INDEX_Z] = *(u32 *)raw_data;
+ incl_state->scan.incl_val[CHANNEL_SCAN_INDEX_Z] = *(u32
*)raw_data;
+ break;
+ case HID_USAGE_SENSOR_TIME_TIMESTAMP:
+ incl_state->timestamp =
+
hid_sensor_convert_timestamp(_state->common_attributes,
+*(s64 *)raw_data);
break;
default:
ret = -EINVAL;
--
2.17.1
[PATCH v3 0/6] add timestamp channel for hid-sensors
This patch series add a timestamp channel for hid sensors, including gravity sensor, gyro sensor, magnetometer sensor, ambient light sensor, inclinometer sensor, and rotation sensor. With this patch series, user can get the time when sensor yield a sample. --- v3: - hid-sensor-magn-3d: fix iio_val buffer len issue. - hid-sensor-accel-3d: refine commit message v2: - remove unrelated changes. Ye Xiang (6): iio: hid-sensor-accel-3d: Add timestamp channel for gravity sensor iio: hid-sensor-gyro-3d: Add timestamp channel iio: hid-sensor-als: Add timestamp channel iio: hid-sensor-magn-3d: Add timestamp channel iio: hid-sensor-incl-3d: Add timestamp channel iio: hid-sensor-rotation: Add timestamp channel drivers/iio/accel/hid-sensor-accel-3d.c | 6 ++- drivers/iio/gyro/hid-sensor-gyro-3d.c | 40 +--- drivers/iio/light/hid-sensor-als.c| 39 --- drivers/iio/magnetometer/hid-sensor-magn-3d.c | 48 --- drivers/iio/orientation/hid-sensor-incl-3d.c | 43 ++--- drivers/iio/orientation/hid-sensor-rotation.c | 46 ++ 6 files changed, 134 insertions(+), 88 deletions(-) -- 2.17.1
[PATCH v3 4/6] iio: hid-sensor-magn-3d: Add timestamp channel
Each sample has a timestamp field with this change. This timestamp may
be from the sensor hub when present or local kernel timestamp. And the
unit of timestamp is nanosecond.
Signed-off-by: Ye Xiang
---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 48 ---
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index cacbd053b2c6..b79c8a5a98f9 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -24,6 +24,7 @@ enum magn_3d_channel {
CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP,
CHANNEL_SCAN_INDEX_NORTH_MAGN,
CHANNEL_SCAN_INDEX_NORTH_TRUE,
+ CHANNEL_SCAN_INDEX_TIMESTAMP,
MAGN_3D_CHANNEL_MAX,
};
@@ -47,6 +48,7 @@ struct magn_3d_state {
struct common_attributes magn_flux_attr;
struct common_attributes rot_attr;
+ s64 timestamp;
};
static const u32 magn_3d_addresses[MAGN_3D_CHANNEL_MAX] = {
@@ -57,6 +59,7 @@ static const u32 magn_3d_addresses[MAGN_3D_CHANNEL_MAX] = {
HID_USAGE_SENSOR_ORIENT_COMP_TRUE_NORTH,
HID_USAGE_SENSOR_ORIENT_MAGN_NORTH,
HID_USAGE_SENSOR_ORIENT_TRUE_NORTH,
+ HID_USAGE_SENSOR_TIME_TIMESTAMP,
};
static const u32 magn_3d_sensitivity_addresses[] = {
@@ -132,7 +135,8 @@ static const struct iio_chan_spec magn_3d_channels[] = {
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
- }
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(7)
};
/* Adjust channel real bits based on report descriptor */
@@ -281,13 +285,6 @@ static const struct iio_info magn_3d_info = {
.write_raw = _3d_write_raw,
};
-/* Function to push data to buffer */
-static void hid_sensor_push_data(struct iio_dev *indio_dev, const void *data)
-{
- dev_dbg(_dev->dev, "hid_sensor_push_data\n");
- iio_push_to_buffers(indio_dev, data);
-}
-
/* Callback handler to send event after all samples are received and captured
*/
static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
unsigned usage_id,
@@ -297,8 +294,15 @@ static int magn_3d_proc_event(struct hid_sensor_hub_device
*hsdev,
struct magn_3d_state *magn_state = iio_priv(indio_dev);
dev_dbg(_dev->dev, "magn_3d_proc_event\n");
- if (atomic_read(_state->magn_flux_attributes.data_ready))
- hid_sensor_push_data(indio_dev, magn_state->iio_vals);
+ if (atomic_read(_state->magn_flux_attributes.data_ready)) {
+ if (!magn_state->timestamp)
+ magn_state->timestamp = iio_get_time_ns(indio_dev);
+
+ iio_push_to_buffers_with_timestamp(indio_dev,
+ magn_state->iio_vals,
+ magn_state->timestamp);
+ magn_state->timestamp = 0;
+ }
return 0;
}
@@ -329,6 +333,11 @@ static int magn_3d_capture_sample(struct
hid_sensor_hub_device *hsdev,
offset = (usage_id - HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH)
+ CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP;
break;
+ case HID_USAGE_SENSOR_TIME_TIMESTAMP:
+ magn_state->timestamp =
+
hid_sensor_convert_timestamp(_state->magn_flux_attributes,
+*(s64 *)raw_data);
+ return ret;
default:
return -EINVAL;
}
@@ -394,9 +403,10 @@ static int magn_3d_parse_report(struct platform_device
*pdev,
return -ENOMEM;
}
- st->iio_vals = devm_kcalloc(>dev, attr_count,
- sizeof(u32),
- GFP_KERNEL);
+ /* attr_count include timestamp channel, and the iio_vals should be
aligned to 8byte */
+ st->iio_vals = devm_kcalloc(>dev,
+ ((attr_count + 1) % 2 + (attr_count + 1) /
2) * 2,
+ sizeof(u32), GFP_KERNEL);
if (!st->iio_vals) {
dev_err(>dev,
"failed to allocate space for iio values array\n");
@@ -412,11 +422,13 @@ static int magn_3d_parse_report(struct platform_device
*pdev,
(_channels[*chan_count]).scan_index = *chan_count;
(_channels[*chan_count]).address = i;
- /* Set magn_val_addr to iio value address */
- st->magn_val_addr[i] = &(st->iio_vals[*chan_count]);
- magn_3d_adjust_channel_bit_mask(_channels,
- *chan_count,
- st->magn[i].size);
+ if (i != CHANNEL_SCAN_INDEX_TIMESTAMP) {
+
Re: [PATCH RFC v4 1/1] scsi: ufs: Fix ufs power down/on specs violation
On 4/01/21 8:55 pm, Bjorn Andersson wrote: > On Mon 04 Jan 03:15 CST 2021, Adrian Hunter wrote: > >> On 22/12/20 3:49 pm, Ziqi Chen wrote: >>> As per specs, e.g, JESD220E chapter 7.2, while powering >>> off/on the ufs device, RST_N signal and REF_CLK signal >>> should be between VSS(Ground) and VCCQ/VCCQ2. >>> >>> To flexibly control device reset line, refactor the function >>> ufschd_vops_device_reset(sturct ufs_hba *hba) to ufshcd_ >>> vops_device_reset(sturct ufs_hba *hba, bool asserted). The >>> new parameter "bool asserted" is used to separate device reset >>> line pulling down from pulling up. >> >> This patch assumes the power is controlled by voltage regulators, but for us >> it is controlled by firmware (ACPI), so it is not correct to change RST_n >> for all host controllers as you are doing. >> >> Also we might need to use a firmware interface for device reset, in which >> case the 'asserted' value doe not make sense. >> > > Are you saying that the entire flip-flop-the-reset is a single firmware > operation in your case? Yes > If you look at the Mediatek driver, the > implementation of ufs_mtk_device_reset_ctrl() is a jump to firmware. > > > But perhaps "asserted" isn't the appropriate English word for saying > "the reset is in the resetting state"? > > I just wanted to avoid the use of "high"/"lo" as if you look at the > Mediatek code they pass the expected line-level to the firmware, while > in the Qualcomm code we pass the logical state to the GPIO code which is > setup up as "active low" and thereby flip the meaning before hitting the > pad. > >> Can we leave the device reset callback alone, and instead introduce a new >> variant operation for setting RST_n to match voltage regulator power changes? > > Wouldn't this new function just have to look like the proposed patches? > In which case for existing platforms we'd have both? > > How would you implement this, or would you simply skip implementing > this? Functionally, doing a device reset is not the same as adjusting signal levels to meet power up/off ramp requirements. However, the issue is that we do not use regulators, so the power is not necessarily being changed at those points, and we definitely do not want to reset instead of entering DeepSleep for example. Off the top of my head, I imagine something like a callback called ufshcd_vops_prepare_power_ramp(hba, bool on) which is called only if hba->vreg_info->vcc is not NULL.
Re: [PATCH] [v2]net:ppp: remove disc_data_lock in ppp line discipline
Hi Greg KH:
On Fri, 1 Jan 2021 09:18:48 +0100, Greg KH wrote:
>On Fri, Jan 01, 2021 at 11:37:18AM +0800, Gao Yan wrote:
>> In tty layer, it provides tty->ldisc_sem to protect all tty_ldisc_ops
>> including ppp_sync_ldisc. So I think tty->ldisc_sem can also protect
>> tty->disc_data, and the disc_data_lock is not necessary.
>>
>> Signed-off-by: Gao Yan
>> ---
>> drivers/net/ppp/ppp_async.c | 11 ++-
>> drivers/net/ppp/ppp_synctty.c | 12 ++--
>> 2 files changed, 4 insertions(+), 19 deletions(-)
>
>What changed from v1?
just change some description.
>And how did you test this? Why remove this lock, is it causing problems
>somewhere for it to be here?
Somedays ago, There is a problem of 4.14 kernel in n_tty line discipline.
Specific description is here:
Link: https://lkml.org/lkml/2020/12/9/339
At the beginning I tried to add a lock in the layer of n_tty, until I find the
patch that helps me a lot.
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.9-rc4=83d817f41070c48bc3eb7ec18e43000a548fca5c
About the patch, Specific description is here:
Link: https://lkml.org/lkml/2018/8/29/555
So after referring to the previous patch, it is unnecessary to add a lock to
protect disc_data in n_tty_close and n_tty_flush_buffer. And
I think it is the same with ppp line discipline.
More detailed explanation:
We have a potential race on dereferencing tty->disc_data, so we should use some
locks to avoid the competition.
In the current version, it defines disc_data_lock to protect the race of
ppp_asynctty_receive and ppp_asynctty_close.
However, I think when cpu A is running ppp_asynctty_receive, another cpu B will
not run ppp_asynctty_close at the same time.
The reasons are as follows:
Cpu A will hold tty->ldisc_sem before running ppp_asynctty_receive. If cpu B
wants to run ppp_asynctty_close,
it must wait until cpu A release tty->ldisc_sem after ppp_asynctty_receive.
So I think tty->ldisc_sem already can protect the tty->disc_data in ppp line
discipline just like n_tty line discipline.
Thanks.
Gao Yan
>Signed-off-by: Gao Yan
>---
> drivers/net/ppp/ppp_async.c | 11 ++-
> drivers/net/ppp/ppp_synctty.c | 12 ++--
> 2 files changed, 4 insertions(+), 19 deletions(-)
>
>diff --git a/drivers/net/ppp/ppp_async.c b/drivers/net/ppp/ppp_async.c
>index 29a0917a8..20b50facd 100644
>--- a/drivers/net/ppp/ppp_async.c
>+++ b/drivers/net/ppp/ppp_async.c
>@@ -127,17 +127,13 @@ static const struct ppp_channel_ops async_ops = {
> * FIXME: this is no longer true. The _close path for the ldisc is
> * now guaranteed to be sane.
> */
>-static DEFINE_RWLOCK(disc_data_lock);
>
> static struct asyncppp *ap_get(struct tty_struct *tty)
> {
>- struct asyncppp *ap;
>+ struct asyncppp *ap = tty->disc_data;
>
>- read_lock(_data_lock);
>- ap = tty->disc_data;
>if (ap != NULL)
>refcount_inc(>refcnt);
>- read_unlock(_data_lock);
>return ap;
> }
>
>@@ -214,12 +210,9 @@ ppp_asynctty_open(struct tty_struct *tty)
> static void
> ppp_asynctty_close(struct tty_struct *tty)
> {
>- struct asyncppp *ap;
>+ struct asyncppp *ap = tty->disc_data;
>
>- write_lock_irq(_data_lock);
>- ap = tty->disc_data;
>tty->disc_data = NULL;
>- write_unlock_irq(_data_lock);
>if (!ap)
>return;
>
>diff --git a/drivers/net/ppp/ppp_synctty.c b/drivers/net/ppp/ppp_synctty.c
>index 0f338752c..53fb68e29 100644
>--- a/drivers/net/ppp/ppp_synctty.c
>+++ b/drivers/net/ppp/ppp_synctty.c
>@@ -129,17 +129,12 @@ ppp_print_buffer (const char *name, const __u8 *buf, int
>count)
> *
> * FIXME: Fixed in tty_io nowadays.
> */
>-static DEFINE_RWLOCK(disc_data_lock);
>-
> static struct syncppp *sp_get(struct tty_struct *tty)
> {
>- struct syncppp *ap;
>+ struct syncppp *ap = tty->disc_data;
>
>- read_lock(_data_lock);
>- ap = tty->disc_data;
>if (ap != NULL)
>refcount_inc(>refcnt);
>- read_unlock(_data_lock);
>return ap;
> }
>
>@@ -213,12 +208,9 @@ ppp_sync_open(struct tty_struct *tty)
> static void
> ppp_sync_close(struct tty_struct *tty)
> {
>- struct syncppp *ap;
>+ struct syncppp *ap = tty->disc_data;
>
>- write_lock_irq(_data_lock);
>- ap = tty->disc_data;
>tty->disc_data = NULL;
>- write_unlock_irq(_data_lock);
>if (!ap)
>return;
>
>--
>2.17.1
>
Re: [RFC PATCH v3 4/5] usb: xhci-mtk: add support runtime pm
Hi Ikjoon,
I try to rebuild the code flow, and want to apply the framework from
wakeirq.c
On Tue, 2020-12-29 at 15:38 +0800, Ikjoon Jang wrote:
> On Tue, Dec 22, 2020 at 5:35 PM Chunfeng Yun
> wrote:
> >
> > From: CK Hu
> >
> > add support runtime pm feature
> >
> > Signed-off-by: Zhanyong Wang
> > Signed-off-by: Chunfeng Yun
> > ---
> > v3:
> > 1. fix some issues
> > 2. remove attribute files
> >
> > v2: fix error caused by request irq suggested by CK
> > ---
> > drivers/usb/host/xhci-mtk.c | 285 +++-
> > drivers/usb/host/xhci-mtk.h | 14 ++
> > 2 files changed, 294 insertions(+), 5 deletions(-)
> > mode change 100755 => 100644 drivers/usb/host/xhci-mtk.c
> >
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > old mode 100755
> > new mode 100644
> > index 34bd3de090b1..c07d54acbcb7
> > --- a/drivers/usb/host/xhci-mtk.c
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -77,6 +78,72 @@ enum ssusb_uwk_vers {
> > SSUSB_UWK_V3,
> > };
> >
> > +int xhci_mtk_runtime_ready;
> > +
> > +static int xhci_mtk_runtime_resume(struct device *dev);
> > +
> > +static void xhci_mtk_seal_work(struct work_struct *work)
> > +{
> > + struct xhci_hcd_mtk *mtk =
> > + container_of(work, struct xhci_hcd_mtk, seal.work);
> > + struct usb_hcd *hcd = mtk->hcd;
> > + struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > +
> > + xhci_dbg(xhci, "spm unseals xHCI controller %i\n",
> > mtk->seal_status);
> > + if (mtk->seal_status == SEAL_SUSPENDED) {
> > + mtk->seal_status = SEAL_RESUMING;
> > + pm_runtime_mark_last_busy(mtk->dev);
> > + pm_runtime_put_sync_autosuspend(mtk->dev);
>
> If I understand correctly, this function is for waking up the device
> but this function calls put() only without get().
will use pm_request_resume();
>
> > + } else {
> > + /*
> > +* FIXME: Sometimes seal_status will keep it on
> > SEAL_RESUMING staus not to expect
> > +* since pm_runtime_put_sync_autosuspend doesn't invoke
> > runtime_resume of callback.
> > +* and to survey why not to invoke runtime_resume callback
> > named
> > +* xhci_mtk_runtime_resume in time in short feature, Herely
> > provide one solution
> > +* that make sure seal_status to match h/w state
> > machine,and MTK xHCI clocks
> > +* on as soon as unseal event received.
>
> I guess actual resuming should be happened only from the 1st interrupt
> (when in SEAL_SUSPENDED)
> and following spurious interrupts can be just ignored.
Yes
>
> > +*/
> > + if (mtk->seal_status == SEAL_RESUMING)
> > + xhci_mtk_runtime_resume(mtk->dev);
>
> xhci_mtk_runtime_resume() is defined as a runtime pm callback,
> pm core will call that callback when pm usage counter reaches to zero.
Yes
>
> > + else
> > + xhci_warn(xhci,
> > + "Ignore seal wakeup source disordered in
> > xHCI controller\n");
> > + }
> > +}
> > +
> > +static irqreturn_t xhci_mtk_seal_irq(int irq, void *data)
> > +{
> > + struct xhci_hcd_mtk *mtk = data;
> > + struct usb_hcd *hcd = mtk->hcd;
> > + struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > +
> > + xhci_dbg(xhci, "seal irq ISR invoked\n");
> > +
> > + schedule_delayed_work(>seal, 0);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static void xhci_mtk_seal_wakeup_enable(struct xhci_hcd_mtk *mtk, bool
> > enable)
> > +{
> > + struct irq_desc *desc;
> > + struct device *dev = mtk->dev;
> > +
> > + if (mtk && mtk->seal_irq) {
> > + desc = irq_to_desc(mtk->seal_irq);
> > + if (enable) {
> > + desc->irq_data.chip->irq_ack(>irq_data);
> > + enable_irq(mtk->seal_irq);
> > + dev_dbg(dev, "%s: enable_irq %i\n",
> > +__func__, mtk->seal_irq);
> > + } else {
> > + disable_irq(mtk->seal_irq);
> > + dev_dbg(dev, "%s: disable_irq %i\n",
> > +__func__, mtk->seal_irq);
> > + }
> > + }
> > +}
> > +
>
> I think this is unnecessary if this driver can check the current state
> and ignore the spurious irqs if spm sometimes triggers the wake-up irqs.
It helps to reduce some irqs, there are many spurious interrupts, I
think there is something wrong from the point of HW, will try to find
the root cause.
>
> > static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
> > {
> > struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
> > @@ -347,7 +414,6 @@ static int
Re: [PATCH 3/3] overlayfs: Report writeback errors on upper
> > > > What I would rather see is: > > - Non-volatile: first syncfs in every container gets an error (nice to have) > > I am not sure why are we making this behavior per container. This should > be no different from current semantics we have for syncfs() on regular > filesystem. And that will provide what you are looking for. If you > want single error to be reported in all ovleray mounts, then make > sure you have one fd open in each mount after mount, then call syncfs() > on that fd. > Ok. > Not sure why overlayfs behavior/semantics should be any differnt > than what regular filessytems like ext4/xfs are offering. Once we > get page cache sharing sorted out with xfs reflink, then people > will not even need overlayfs and be able to launch containers > just using xfs reflink and share base image. In that case also > they will need to keep an fd open per container they want to > see an error in. > > So my patches exactly provide that. syncfs() behavior is same with > overlayfs as application gets it on other filesystems. And to me > its important to keep behavior same. > > > - Volatile: every syncfs and every fsync in every container gets an error > > (important IMO) > > For volatile mounts, I agree that we need to fail overlayfs instance > as soon as first error is detected since mount. And this applies to > not only syncfs()/fsync() but to read/write and other operations too. > > For that we will need additional patches which are floating around > to keep errseq sample in overlay and check for errors in all > paths syncfs/fsync/read/write/ and fail fs. > But these patches build on top of my patches. Here we disagree. I don't see how Jeff's patch is "building on top of your patches" seeing that it is perfectly well contained and does not in fact depend on your patches. And I do insist that the fix for volatile mounts syncfs/fsync error reporting should be applied before your patches or at the very least not heavily depend on them. volatile mount was introduced in fresh new v5.10, which is also an LTS kernel. It would be inconsiderate of volatile mount users and developers to make backporting that fix to v5.10.y any harder than it should be. > My patches don't solve this problem of failing overlay mount for > the volatile mount case. > Here we agree. > > > > This is why I prefer to sample upper sb error on mount and propagate > > new errors to overlayfs sb (Jeff's patch). > > Ok, I think this is one of the key points of the whole discussion. What > mechanism should be used to propagate writeback errors through overlayfs. > > A. Propagate errors from upper sb to overlay sb. > B. Leave overlay sb alone and use upper sb for error checks. > > We don't have good model to propagate errors between super blocks, > so Jeff preferred not to do error propagation between super blocks > for regular mounts. > > https://lore.kernel.org/linux-fsdevel/bff90dfee3a3392d67a4f3516ab28989e87fa25f.ca...@kernel.org/ > > If we are not defining new semantics for syncfs() for overlayfs, then > I can't see what's the advantage of coming up with new mechanism to > propagate errors to overlay sb. Approach B should work just fine and > provide the syncfs() semantics we want for overlayfs (Same semantics > as other filesystems). > Ok. I am on board with B. Philosophically. overlayfs model is somewhere between "passthrough" and "proxy" when handling pure upper files and as overlayfs evolves, it steadily moves towards the "proxy" model, with page cache and writeback being the largest remaining piece to convert. So I concede that as long as overlayfs writeback is mostly passthrough, syncfs might as well be passthrough to upper fs as well. Thanks, Amir.
Re: [External] Re: [PATCH 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page
On Tue, Jan 5, 2021 at 2:38 PM HORIGUCHI NAOYA(堀口 直也)
wrote:
>
> On Mon, Jan 04, 2021 at 02:58:41PM +0800, Muchun Song wrote:
> > When dissolve_free_huge_page() races with __free_huge_page(), we can
> > do a retry. Because the race window is small.
> >
> > Signed-off-by: Muchun Song
> > ---
> > mm/hugetlb.c | 16 +++-
> > 1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 72608008f8b4..db00ae375d2a 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1763,10 +1763,11 @@ static int free_pool_huge_page(struct hstate *h,
> > nodemask_t *nodes_allowed,
> > * nothing for in-use hugepages and non-hugepages.
> > * This function returns values like below:
> > *
> > - * -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
> > - * (allocated or reserved.)
> > - * 0: successfully dissolved free hugepages or the page is not a
> > - * hugepage (considered as already dissolved)
> > + * -EAGAIN: race with __free_huge_page() and can do a retry
> > + * -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
> > + * (allocated or reserved.)
> > + * 0: successfully dissolved free hugepages or the page is not a
> > + * hugepage (considered as already dissolved)
> > */
> > int dissolve_free_huge_page(struct page *page)
> > {
> > @@ -1815,8 +1816,10 @@ int dissolve_free_huge_page(struct page *page)
> >* We should make sure that the page is already on the free
> > list
> >* when it is dissolved.
> >*/
> > - if (unlikely(!PageHugeFreed(head)))
> > + if (unlikely(!PageHugeFreed(head))) {
> > + rc = -EAGAIN;
> > goto out;
> > + }
>
> If dissolve_free_huge_page() races with __free_huge_page() and we detect
> it with this check, the hugepage is expected to be freed or dissolved by
> __free_huge_page(), so is it enough just to return with rc = 0 without
> retrying?
The dissolve_free_huge_page() aims to free the page to the buddy
allocator not the hugepage pool. So it is not enough just to return 0,
right? Or did you mean that we set the page temporary here and
let the __free_huge_page do the freeing later for us? Thanks.
>
> Thanks,
> Naoya Horiguchi
>
> >
> > /*
> >* Move PageHWPoison flag from head page to the raw error
> > page,
> > @@ -1857,7 +1860,10 @@ int dissolve_free_huge_pages(unsigned long
> > start_pfn, unsigned long end_pfn)
> >
> > for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) {
> > page = pfn_to_page(pfn);
> > +retry:
> > rc = dissolve_free_huge_page(page);
> > + if (rc == -EAGAIN)
> > + goto retry;
> > if (rc)
> > break;
> > }
> > --
> > 2.11.0
> >
[PATCH v2] drivers core: Free dma_range_map when driver probe failed
From: Meng Li There will be memory leak if driver probe failed. Trace as below: backtrace: [<2415258f>] kmemleak_alloc+0x3c/0x50 [] __kmalloc+0x208/0x530 [<48bc7b3a>] of_dma_get_range+0xe4/0x1b0 [<41e39065>] of_dma_configure_id+0x58/0x27c [<6356866a>] platform_dma_configure+0x2c/0x40 .. [<0afcf9b5>] ret_from_fork+0x10/0x3c This issue is introduced by commit e0d072782c73("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset "). It doesn't free dma_range_map when driver probe failed and cause above memory leak. So, add code to free it in error path. v2: set dev->dma_range_map as NULL after memory free. Fixes: e0d072782c73("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset ") Cc: sta...@vger.kernel.org Signed-off-by: Meng Li --- drivers/base/dd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 148e81969e04..3c94ebc8d4bb 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -612,6 +612,8 @@ static int really_probe(struct device *dev, struct device_driver *drv) else if (drv->remove) drv->remove(dev); probe_failed: + kfree(dev->dma_range_map); + dev->dma_range_map = NULL; if (dev->bus) blocking_notifier_call_chain(>bus->p->bus_notifier, BUS_NOTIFY_DRIVER_NOT_BOUND, dev); -- 2.17.1
[PATCH v2] fs/buffer.c: Revoke LRU when trying to drop buffers
From: Laura Abbott
When a buffer is added to the LRU list, a reference is taken which is
not dropped until the buffer is evicted from the LRU list. This is the
correct behavior, however this LRU reference will prevent the buffer
from being dropped. This means that the buffer can't actually be dropped
until it is selected for eviction. There's no bound on the time spent
on the LRU list, which means that the buffer may be undroppable for
very long periods of time. Given that migration involves dropping
buffers, the associated page is now unmigratible for long periods of
time as well. CMA relies on being able to migrate a specific range
of pages, so these types of failures make CMA significantly
less reliable, especially under high filesystem usage.
Rather than waiting for the LRU algorithm to eventually kick out
the buffer, explicitly remove the buffer from the LRU list when trying
to drop it. There is still the possibility that the buffer
could be added back on the list, but that indicates the buffer is
still in use and would probably have other 'in use' indicates to
prevent dropping.
Signed-off-by: Laura Abbott
Signed-off-by: Chris Goldsworthy
Cc: Matthew Wilcox
---
fs/buffer.c | 85 +++
fs/internal.h | 5
2 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 96c7604..536fb5b 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -1471,12 +1472,63 @@ static bool has_bh_in_lru(int cpu, void *dummy)
return false;
}
+static void __evict_bhs_lru(void *arg)
+{
+ struct bh_lru *b = _cpu_var(bh_lrus);
+ struct busy_bhs_container *busy_bhs = arg;
+ struct buffer_head *bh;
+ int i;
+
+ XA_STATE(xas, _bhs->xarray, 0);
+
+ xas_for_each(, bh, busy_bhs->size) {
+ for (i = 0; i < BH_LRU_SIZE; i++) {
+ if (b->bhs[i] == bh) {
+ brelse(b->bhs[i]);
+ b->bhs[i] = NULL;
+ break;
+ }
+ }
+
+ bh = bh->b_this_page;
+ }
+
+ put_cpu_var(bh_lrus);
+}
+
+static bool page_has_bhs_in_lru(int cpu, void *arg)
+{
+ struct bh_lru *b = per_cpu_ptr(_lrus, cpu);
+ struct busy_bhs_container *busy_bhs = arg;
+ struct buffer_head *bh;
+ int i;
+
+ XA_STATE(xas, _bhs->xarray, 0);
+
+ xas_for_each(, bh, busy_bhs->size) {
+ for (i = 0; i < BH_LRU_SIZE; i++) {
+ if (b->bhs[i] == bh)
+ return true;
+ }
+
+ bh = bh->b_this_page;
+ }
+
+ return false;
+
+}
void invalidate_bh_lrus(void)
{
on_each_cpu_cond(has_bh_in_lru, invalidate_bh_lru, NULL, 1);
}
EXPORT_SYMBOL_GPL(invalidate_bh_lrus);
+static void evict_bh_lrus(struct busy_bhs_container *busy_bhs)
+{
+ on_each_cpu_cond(page_has_bhs_in_lru, __evict_bhs_lru,
+busy_bhs, 1);
+}
+
void set_bh_page(struct buffer_head *bh,
struct page *page, unsigned long offset)
{
@@ -3242,14 +3294,36 @@ drop_buffers(struct page *page, struct buffer_head
**buffers_to_free)
{
struct buffer_head *head = page_buffers(page);
struct buffer_head *bh;
+ struct busy_bhs_container busy_bhs;
+ int xa_ret, ret = 0;
+
+ xa_init(_bhs.xarray);
+ busy_bhs.size = 0;
bh = head;
do {
- if (buffer_busy(bh))
- goto failed;
+ if (buffer_busy(bh)) {
+ xa_ret = xa_err(xa_store(_bhs.xarray,
busy_bhs.size++,
+bh, GFP_ATOMIC));
+ if (xa_ret)
+ goto out;
+ }
bh = bh->b_this_page;
} while (bh != head);
+ if (busy_bhs.size) {
+ /*
+* Check if the busy failure was due to an outstanding
+* LRU reference
+*/
+ evict_bh_lrus(_bhs);
+ do {
+ if (buffer_busy(bh))
+ goto out;
+ } while (bh != head);
+ }
+
+ ret = 1;
do {
struct buffer_head *next = bh->b_this_page;
@@ -3259,9 +,10 @@ drop_buffers(struct page *page, struct buffer_head
**buffers_to_free)
} while (bh != head);
*buffers_to_free = head;
detach_page_private(page);
- return 1;
-failed:
- return 0;
+out:
+ xa_destroy(_bhs.xarray);
+
+ return ret;
}
int try_to_free_buffers(struct page *page)
diff --git a/fs/internal.h b/fs/internal.h
index 77c50be..00f17c4 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -15,6 +15,7 @@ struct mount;
struct shrink_control;
[PATCH v2] Resolve LRU page-pinning issue for file-backed pages
It is possible for file-backed pages to end up in a contiguous memory area (CMA), such that the relevant page must be migrated using the .migratepage() callback when its backing physical memory is selected for use in an CMA allocation (through cma_alloc()). However, if a set of address space operations (AOPs) for a file-backed page lacks a migratepage() page call-back, fallback_migrate_page() will be used instead, which through try_to_release_page() calls try_to_free_buffers() (which is called directly or through a try_to_free_buffers() callback. try_to_free_buffers() in turn calls drop_buffers() drop_buffers() itself can fail due to the buffer_head associated with a page being busy. However, it is possible that the buffer_head is on an LRU list for a CPU, such that we can try removing the buffer_head from that list, in order to successfully release the page. Do this. v1: https://lore.kernel.org/lkml/cover.1606194703.git.cgold...@codeaurora.org/T/#m3a44b5745054206665455625ccaf27379df8a190 Original version of the patch (with updates to make to account for changes in on_each_cpu_cond()). v2: Follow Matthew Wilcox's suggestion of reducing the number of calls to on_each_cpu_cond(), by iterating over a page's busy buffer_heads inside of on_each_cpu_cond(). To copy from his e-mail, we go from: for_each_buffer for_each_cpu for_each_lru_entry to: for_each_cpu for_each_buffer for_each_lru_entry This is done using xarrays, which I found to be the cleanest data structure to use, though a pre-allocated array of page_size(page) / bh->b_size elements might be more performant. Laura Abbott (1): fs/buffer.c: Revoke LRU when trying to drop buffers fs/buffer.c | 85 +++ fs/internal.h | 5 2 files changed, 85 insertions(+), 5 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
RE: [PATCH v2] drivers core: Free dma_range_map when driver probe failed
> -Original Message- > From: Greg KH > Sent: Tuesday, January 5, 2021 2:01 PM > To: Li, Meng > Cc: linux-kernel@vger.kernel.org; raf...@kernel.org; > james.quin...@broadcom.com; Hao, Kexin > Subject: Re: [PATCH v2] drivers core: Free dma_range_map when driver > probe failed > > On Tue, Jan 05, 2021 at 01:41:48PM +0800, meng...@windriver.com wrote: > > From: Limeng > > This does not match your signed-off-by line :( I will fix it. Thanks, Limeng
[PATCH] selftests/ftrace: Disable multiple_kprobes test on powerpc
Not all symbols are blacklisted on powerpc. Disable multiple_kprobes test until that is sorted, so that rest of ftrace and kprobe selftests can be run. Signed-off-by: Naveen N. Rao --- .../testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc index 312d237800969e..41503c32f53eed 100644 --- a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc +++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc @@ -7,7 +7,7 @@ # Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc64le case `uname -m` in x86_64|i[3456]86) OFFS=5;; - ppc64le) OFFS=8;; + ppc*) exit_unsupported;; *) OFFS=0;; esac base-commit: 36bbbd0e234d817938bdc52121a0f5473b3e58f5 -- 2.25.4
Re: [PATCH v4 15/15] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
Hi Dan,
On 04/01/2021 22:02, Daniel Scally wrote:
> On 04/01/2021 13:35, Kieran Bingham wrote:
>>> +/*
>>> + * Extend this array with ACPI Hardware IDs of devices known to be
>>> working
>>> + * plus the number of link-frequencies expected by their drivers,
>>> along with
>>> + * the frequency values in hertz. This is somewhat opportunistic way
>>> of adding
>>> + * support for this for now in the hopes of a better source for the
>>> information
>>> + * (possibly some encoded value in the SSDB buffer that we're unaware
>>> of)
>>> + * becoming apparent in the future.
>>> + *
>>> + * Do not add an entry for a sensor that is not actually supported.
>>> + */
>>> +static const struct cio2_sensor_config cio2_supported_sensors[] = {
>>> + CIO2_SENSOR_CONFIG("INT33BE", 0),
>>> + CIO2_SENSOR_CONFIG("OVTI2680", 0),
>> I don't know if these are expressed anywhere else but would it be
>> helpful to add a comment, or indicator as to what the actual sensor is
>> that is represented by this HID?
>>
>> I can make an assumption about what an OVTI2680 might be, but the
>> INT33BE is quite opaque. It's not clear what support that adds.
>>
>> Unless no one cares what the sensor is that is, but I would anticipate
>> anyone looking here to add a new sensor might want to investigate what
>> was already in the table?
> Yeah good point. I'll probably alternate comment and entry then, like:
>
>
> +static const struct cio2_sensor_config cio2_supported_sensors[] = {
> + /* Sensor OVTI5693 */
> + CIO2_SENSOR_CONFIG("INT33BE", 0),
> + /* Sensor OVTI2680 */
> + CIO2_SENSOR_CONFIG("OVTI2680", 0),
>
> As an inline comment won't fit for the sensors that we know
> link-frequencies for. That sound ok?
I might put the whole vendor name in, and no need to prefix 'Sensor' IMO.
+ /* Omnivision OV5693 */
+ CIO2_SENSOR_CONFIG("INT33BE", 0),
+ /* Omnivision OV2680 */
+ CIO2_SENSOR_CONFIG("OVTI2680", 0),
but otherwise, yes a comment the line before works for me, as you are
right - at the end would not be practical.
>>> Works for me
>>> +static void cio2_bridge_create_fwnode_properties(
>>> + struct cio2_sensor *sensor,
>>> + const struct cio2_sensor_config *cfg)
>>> +{
>>> + unsigned int i;
>>> +
>>> + sensor->prop_names = prop_names;
>>> +
>>> + for (i = 0; i < CIO2_MAX_LANES; i++)
>>> + sensor->data_lanes[i] = i + 1;
>> Does something support lane swapping somewhere?
>> I assume this is just mapping each lane directly through.
> I think Sakari said remapping isn't supported in the CIO2 - so yeah this
> is just mapping them directly
So is this needed? Or is it some future compatibility thing?
I haven't seen where it's used yet, but I'm not too worried about it
though, just not sure what value an array of [1, 2, 3, 4] gives if it's
constant...
>>>
>>> The endpoints need to have the data-lanes property which passes an array
>>> of data lanes, but there may well be a better way of doing this. I'm
>>> just using the lanes member of the ssdb data structure to tell the
>>> property how many members of the array to look at:
>>>
>>>
>>> + sensor->cio2_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN(
>>> + sensor->prop_names.data_lanes,
>>> + sensor->data_lanes,
>>> + sensor->ssdb.lanes);
>>>
>>>
>>> So if sensor->ssdb.lanes is 2, even though it's passed a pointer to the
>>> first member of an array of 4 members, the size calculation of that
>>> macro limits it to just those in use. I.E. if sensor->ssdb.lanes is 2
>>> then the property will be given the size 2 * sizeof(u32), and so when
>>> its parsed only [1, 2] will be read.
>>
>>
>> Aha, I see, ok - so we are populating an array of [1, 2, 3, 4] for each
>> sensor that we add.
>>
>> What about creating the data_lanes once as a const static array and
>> mapping to that?
>>
>> /*
>> * Map the lane arrangement, which is fixed for the IPU3.
>> */
>> static const int data_lanes[CIO2_MAX_LANES] = { 1, 2, 3, 4 };
>
>
> Can't do exactly this; the bridge needs to store everything on heap
> incase the module is unloaded, but I could move the data_lanes array to
> the struct cio2_bridge instead of against each sensor and then we're
> only doing it once.
Ahh, yes I remember reading about that already.
It maybe worth adding a comment about that in this file, to prevent
other people from 'optimising' things out in 5 years ...
It probably doesn't make much difference in that case if it's per sensor
or per bridge. But indeed at least in the bridge it's only created once.
--
Kieran
>
>> ...
>>
>>sensor->cio2_properties[0] = PROPERTY_ENTRY_U32_ARRAY_LEN(
>>
Re: [PATCH 1/2] Documentation: devicetree: Add new compatible string for eeprom microchip 93LC46B
Hi Rob, On 01/01/21 12:47 am, Rob Herring wrote: > On Fri, Dec 18, 2020 at 07:38:10PM +0530, Aswath Govindraju wrote: >> Add a new compatible string for eeprom microchip 93LC46B in eeprom-93xx46 >> dt-binding file as it belongs to the 93xx46 family of devices. >> >> Signed-off-by: Aswath Govindraju >> --- >> Documentation/devicetree/bindings/misc/eeprom-93xx46.txt | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt >> b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt >> index a8ebb4621f79..9f272361f117 100644 >> --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt >> +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt >> @@ -4,6 +4,7 @@ Required properties: >> - compatible : shall be one of: >> "atmel,at93c46d" >> "eeprom-93xx46" >> +"microchip,93LC46B" > > Generally, we use lowercase and that's the existing pattern here. ohh ok. I was trying to match the compatible string exactly with the the device name. I will make this change in the respin. Thanks, Aswath > >> - data-size : number of data bits per word (either 8 or 16) >> >> Optional properties: >> -- >> 2.17.1 >>
Re: [PATCH 5.10 637/717] drm/amd/display: Fix memory leaks in S3 resume
On Mon, Jan 04, 2021 at 08:04:08PM +0100, Andre Tomt wrote: > On 28.12.2020 13:50, Greg Kroah-Hartman wrote: > > From: Stylon Wang > > > > commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362 upstream. > > > > EDID parsing in S3 resume pushes new display modes > > to probed_modes list but doesn't consolidate to actual > > mode list. This creates a race condition when > > amdgpu_dm_connector_ddc_get_modes() re-initializes the > > list head without walking the list and results in memory leak. > > This commit is causing me problems on 5.10.4: when I turn off the display (a > LG TV in this case), and turn it back on again later there is no video > output and I get the following in the kernel log: > > [ 8245.259628] [drm:dm_restore_drm_connector_state [amdgpu]] *ERROR* > Restoring old state failed with -12 > > I've found another report on this commit as well: > https://bugzilla.kernel.org/show_bug.cgi?id=211033 > > And I suspect this is the same: > https://bugs.archlinux.org/task/69202 > > Reverting it from 5.10.4 makes things behave again. > > Have not tested 5.4.86 or 5.11-rc. > > I'm using a RX570 Polaris based card. Can you test 5.11-rc to see if this issue is there as well? thanks, greg k-h
Re: [Linaro-mm-sig] [PATCH] dmabuf: fix use-after-free of dmabuf's file->f_inode
Hi Charan,
On Mon, 4 Jan 2021 at 17:22, Christian König
wrote:
>
> Am 04.01.21 um 12:36 schrieb Charan Teja Reddy:
> > It is observed 'use-after-free' on the dmabuf's file->f_inode with the
> > race between closing the dmabuf file and reading the dmabuf's debug
> > info.
> >
> > Consider the below scenario where P1 is closing the dma_buf file
> > and P2 is reading the dma_buf's debug info in the system:
> >
> > P1P2
> > dma_buf_debug_show()
> > dma_buf_put()
> >__fput()
> > file->f_op->release()
> > dput()
> >
> >dentry_unlink_inode()
> > iput(dentry->d_inode)
> > (where the inode is freed)
> > mutex_lock(_list.lock)
> > read 'dma_buf->file->f_inode'
> > (the same inode is freed by P1)
> > mutex_unlock(_list.lock)
> >dentry->d_op->d_release()-->
> > dma_buf_release()
> >.
> >mutex_lock(_list.lock)
> >removes the dmabuf from the list
> >mutex_unlock(_list.lock)
> >
> > In the above scenario, when dma_buf_put() is called on a dma_buf, it
> > first frees the dma_buf's file->f_inode(=dentry->d_inode) and then
> > removes this dma_buf from the system db_list. In between P2 traversing
> > the db_list tries to access this dma_buf's file->f_inode that was freed
> > by P1 which is a use-after-free case.
> >
> > Since, __fput() calls f_op->release first and then later calls the
> > d_op->d_release, move the dma_buf's db_list removal from d_release() to
> > f_op->release(). This ensures that dma_buf's file->f_inode is not
> > accessed after it is released.
> >
> > Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to
> > dentry_ops")
> > Signed-off-by: Charan Teja Reddy
>
> Not an expert on the debugfs stuff in DMA-buf, but the explanation
> sounds perfectly correct to me.
>
> Acked-by: Christian König
Thanks for your fix; I will queue it up in the fixes branch. Can you
please also send it to be queued to 5.4+ stable branches?
>
> > ---
> > drivers/dma-buf/dma-buf.c | 21 +
> > 1 file changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 0eb80c1..a14dcbb 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -76,10 +76,6 @@ static void dma_buf_release(struct dentry *dentry)
> >
> > dmabuf->ops->release(dmabuf);
> >
> > - mutex_lock(_list.lock);
> > - list_del(>list_node);
> > - mutex_unlock(_list.lock);
> > -
> > if (dmabuf->resv == (struct dma_resv *)[1])
> > dma_resv_fini(dmabuf->resv);
> >
> > @@ -88,6 +84,22 @@ static void dma_buf_release(struct dentry *dentry)
> > kfree(dmabuf);
> > }
> >
> > +static int dma_buf_file_release(struct inode *inode, struct file *file)
> > +{
> > + struct dma_buf *dmabuf;
> > +
> > + if (!is_dma_buf_file(file))
> > + return -EINVAL;
> > +
> > + dmabuf = file->private_data;
> > +
> > + mutex_lock(_list.lock);
> > + list_del(>list_node);
> > + mutex_unlock(_list.lock);
> > +
> > + return 0;
> > +}
> > +
> > static const struct dentry_operations dma_buf_dentry_ops = {
> > .d_dname = dmabuffs_dname,
> > .d_release = dma_buf_release,
> > @@ -413,6 +425,7 @@ static void dma_buf_show_fdinfo(struct seq_file *m,
> > struct file *file)
> > }
> >
> > static const struct file_operations dma_buf_fops = {
> > + .release= dma_buf_file_release,
> > .mmap = dma_buf_mmap_internal,
> > .llseek = dma_buf_llseek,
> > .poll = dma_buf_poll,
>
Best,
Sumit.
Re: [PATCH v3] ovl: use a dedicated semaphore for dir upperfile caching
On Tue, Jan 5, 2021 at 2:36 AM Icenowy Zheng wrote:
>
> The function ovl_dir_real_file() currently uses the semaphore of the
> inode to synchronize write to the upperfile cache field.
Although the inode lock is a rw_sem it is referred to as the "inode lock"
and you also left semaphore in the commit subject.
No need to re-post. This can be fixed on commit.
>
> However, this function will get called by ovl_ioctl_set_flags(), which
> utilizes the inode semaphore too. In this case ovl_dir_real_file() will
> try to claim a lock that is owned by a function in its call stack, which
> won't get released before ovl_dir_real_file() returns.
>
> Define a dedicated semaphore for the upperfile cache, so that the
> deadlock won't happen.
>
> Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR ioctls for
> directories")
> Cc: sta...@vger.kernel.org # v5.10
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v2:
> - Fixed missing replacement in error handling path.
> Changes in v3:
> - Use mutex instead of semaphore.
>
> fs/overlayfs/readdir.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
> index 01620ebae1bd..3980f9982f34 100644
> --- a/fs/overlayfs/readdir.c
> +++ b/fs/overlayfs/readdir.c
> @@ -56,6 +56,7 @@ struct ovl_dir_file {
> struct list_head *cursor;
> struct file *realfile;
> struct file *upperfile;
> + struct mutex upperfile_mutex;
That's a very specific name.
This mutex protects members of struct ovl_dir_file, which could evolve
into struct ovl_file one day (because no reason to cache only dir upper file),
so I would go with a more generic name, but let's leave it to Miklos to decide.
He could have a different idea altogether for fixing this bug.
Thanks,
Amir.
Re: [PATCH 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page
On Mon, Jan 04, 2021 at 02:58:41PM +0800, Muchun Song wrote:
> When dissolve_free_huge_page() races with __free_huge_page(), we can
> do a retry. Because the race window is small.
>
> Signed-off-by: Muchun Song
> ---
> mm/hugetlb.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 72608008f8b4..db00ae375d2a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1763,10 +1763,11 @@ static int free_pool_huge_page(struct hstate *h,
> nodemask_t *nodes_allowed,
> * nothing for in-use hugepages and non-hugepages.
> * This function returns values like below:
> *
> - * -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
> - * (allocated or reserved.)
> - * 0: successfully dissolved free hugepages or the page is not a
> - * hugepage (considered as already dissolved)
> + * -EAGAIN: race with __free_huge_page() and can do a retry
> + * -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
> + * (allocated or reserved.)
> + * 0: successfully dissolved free hugepages or the page is not a
> + * hugepage (considered as already dissolved)
> */
> int dissolve_free_huge_page(struct page *page)
> {
> @@ -1815,8 +1816,10 @@ int dissolve_free_huge_page(struct page *page)
>* We should make sure that the page is already on the free list
>* when it is dissolved.
>*/
> - if (unlikely(!PageHugeFreed(head)))
> + if (unlikely(!PageHugeFreed(head))) {
> + rc = -EAGAIN;
> goto out;
> + }
If dissolve_free_huge_page() races with __free_huge_page() and we detect
it with this check, the hugepage is expected to be freed or dissolved by
__free_huge_page(), so is it enough just to return with rc = 0 without retrying?
Thanks,
Naoya Horiguchi
>
> /*
>* Move PageHWPoison flag from head page to the raw error page,
> @@ -1857,7 +1860,10 @@ int dissolve_free_huge_pages(unsigned long start_pfn,
> unsigned long end_pfn)
>
> for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) {
> page = pfn_to_page(pfn);
> +retry:
> rc = dissolve_free_huge_page(page);
> + if (rc == -EAGAIN)
> + goto retry;
> if (rc)
> break;
> }
> --
> 2.11.0
>
kernel BUG at fs/ext4/ext4.h:LINE!
Hello, syzbot found the following issue on: HEAD commit:f6e1ea19 Merge tag 'ceph-for-5.11-rc2' of git://github.com.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1364b1a350 kernel config: https://syzkaller.appspot.com/x/.config?x=2455d075a1c4afa8 dashboard link: https://syzkaller.appspot.com/bug?extid=b2947dd3e8c72dbe609b compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b2947dd3e8c72dbe6...@syzkaller.appspotmail.com [ cut here ] kernel BUG at fs/ext4/ext4.h:3221! invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 12285 Comm: syz-executor.5 Not tainted 5.11.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ext4_get_group_info fs/ext4/ext4.h:3221 [inline] RIP: 0010:ext4_get_group_info+0x340/0x3a0 fs/ext4/ext4.h:3216 Code: ff 48 c7 c2 c0 03 5f 89 be 83 02 00 00 48 c7 c7 a0 ff 5e 89 c6 05 6c 40 d2 0a 01 e8 f9 59 aa 06 e9 e4 fd ff ff e8 20 9e 69 ff <0f> 0b e8 c9 31 ac ff e9 16 fd ff ff e8 bf 31 ac ff e9 50 fd ff ff RSP: 0018:c90002ddfc58 EFLAGS: 00010293 RAX: RBX: 75e0 RCX: RDX: 88806a563780 RSI: 8208d670 RDI: 0003 RBP: 888021ef R08: 0010 R09: R10: 8208d3a0 R11: R12: 888021eee000 R13: 0010 R14: 888021eee678 R15: c90002ddfd60 FS: 02296940() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 5643b7305d18 CR3: 2b612000 CR4: 00350ee0 Call Trace: ext4_mb_load_buddy_gfp+0xc6/0x1350 fs/ext4/mballoc.c:1156 ext4_discard_preallocations+0x8c6/0xea0 fs/ext4/mballoc.c:4400 ext4_release_file+0x2f0/0x370 fs/ext4/file.c:150 __fput+0x283/0x920 fs/file_table.c:280 task_work_run+0xdd/0x190 kernel/task_work.c:140 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:174 [inline] exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:201 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline] syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x417b71 Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 a4 1a 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:7ffe30828230 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0005 RCX: 00417b71 RDX: RSI: 88edf75e RDI: 0004 RBP: 0001 R08: 8128f848 R09: 06ccd617 R10: 7ffe30828310 R11: 0293 R12: 0119ca00 R13: 0119ca00 R14: 03e8 R15: 0119c0dc Modules linked in: ---[ end trace 321f8951b9d369a1 ]--- RIP: 0010:ext4_get_group_info fs/ext4/ext4.h:3221 [inline] RIP: 0010:ext4_get_group_info+0x340/0x3a0 fs/ext4/ext4.h:3216 Code: ff 48 c7 c2 c0 03 5f 89 be 83 02 00 00 48 c7 c7 a0 ff 5e 89 c6 05 6c 40 d2 0a 01 e8 f9 59 aa 06 e9 e4 fd ff ff e8 20 9e 69 ff <0f> 0b e8 c9 31 ac ff e9 16 fd ff ff e8 bf 31 ac ff e9 50 fd ff ff RSP: 0018:c90002ddfc58 EFLAGS: 00010293 RAX: RBX: 75e0 RCX: RDX: 88806a563780 RSI: 8208d670 RDI: 0003 RBP: 888021ef R08: 0010 R09: R10: 8208d3a0 R11: R12: 888021eee000 R13: 0010 R14: 888021eee678 R15: c90002ddfd60 FS: 02296940() GS:8880b9e0() knlGS: --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: PROBLEM: Firmware loader fallback mechanism no longer works with sendfile
On Mon, Jan 04, 2021 at 02:43:45PM -0800, Siddharth Gupta wrote:
> Hi all,
>
> With the introduction of the filesystem change "fs: don't allow splice
> read/write without explicit ops"[1] the fallback mechanism of the firmware
> loader[2] no longer works when using sendfile[3] from the userspace.
What userspace program are you using to load firmware? Are you not
using the in-kernel firmware loader for some reason?
> Since the binary attributes don't support splice_{read,write} functions the
> calls to splice_{read,write} used the default kernel_{read,write} functions.
> With the above change this results in an -EINVAL return from
> do_splice_from[4].
>
> This essentially means that sendfile will not work for any binary attribute
> in the sysfs.
Have you tried fixing this with a patch much like what we did for the
proc files that needed this? If not, can you?
> [1]:
> https://github.com/torvalds/linux/commit/36e2c7421f02a22f71c9283e55fdb672a9eb58e7#diff-70c49af2ed5805fc1406ed6e6532d6a029ada1abd90cca6442711b9cecd4d523
> [2]:
> https://github.com/torvalds/linux/blob/master/drivers/base/firmware_loader/main.c#L831
> [3]: https://github.com/torvalds/linux/blob/master/fs/read_write.c#L1257
> [4]: https://github.com/torvalds/linux/blob/master/fs/splice.c#L753
kernel development is on git.kernel.org, not github :)
thanks,
greg k-h
Re: [PATCH v8, 5/6] drm/mediatek: add RDMA fifo size error handle
On Mon, 2020-12-14 at 22:54 +0800, Chun-Kuang Hu wrote: > Hi, Yongqiang: > > Yongqiang Niu 於 2020年12月11日 週五 上午8:45寫道： > > > > On Thu, 2020-12-10 at 23:50 +0800, Chun-Kuang Hu wrote: > > > Hi, Yongqiang: > > > > > > Yongqiang Niu 於 2020年12月10日 週四 下午5:08寫道： > > > > > > > > This patch add RDMA fifo size error handle > > > > rdma fifo size will not always bigger than the calculated threshold > > > > if that case happened, we need set fifo size as the threshold > > > > > > > > Signed-off-by: Yongqiang Niu > > > > --- > > > > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > index 794acc5..0508392 100644 > > > > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > @@ -151,6 +151,10 @@ static void mtk_rdma_config(struct mtk_ddp_comp > > > > *comp, unsigned int width, > > > > * account for blanking, and with a pixel depth of 4 bytes: > > > > */ > > > > threshold = width * height * vrefresh * 4 * 7 / 100; > > > > + > > > > + if (threshold > rdma_fifo_size) > > > > + threshold = rdma_fifo_size; > > > > > > If the formula is not correct, you should fix the formula not work around. > > > > > > Regards, > > > Chun-Kuang. > > > > how about this: > > threshold = max(width * height * vrefresh * 4 * 7 / 100, > > rdma_fifo_size); > > When I use width = 1920, height = 1080, vrefresh = 60 to calculate, I > get threshold = 2985. > So I think set threshold to half of fifo size is OK for MAX_WIDTH, > MAX_HEIGHT, MAX_VREFRESH (these three may be different in each SoC) > > threshold = RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) / 2; > > But I worry half fifo size is too big for small resolution and let > small resolution too easy to trigger burst read DRAM. So let the > formula to be this: > > threshold = RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) * width * height * > vrefresh / 2 / MAX_WIDTH / MAX_HEIGHT / MAX_VREFRESH; > > How do you think about this? > > Regards, > Chun-Kuang. how about remove this formula, and set threshold = rdma_fifo_size > > > > > > > > + > > > > reg = RDMA_FIFO_UNDERFLOW_EN | > > > > RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) | > > > > RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold); > > > > -- > > > > 1.8.1.1.dirty > > > > ___ > > > > Linux-mediatek mailing list > > > > linux-media...@lists.infradead.org > > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek > >
Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
On 12/25/2020 6:50 AM, Peter Geis wrote:
External email: Use caution opening links or attachments
Currently hda on tegra30 fails to open a stream with an input/output error.
This is similar to the issue referenced in [1].
For example:
speaker-test -Dhw:0,3 -c 2
speaker-test 1.2.2
Playback device is hw:0,3
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 16384
Period size range from 32 to 8192
Using max buffer size 16384
Periods = 4
was set period_size = 4096
was set buffer_size = 16384
0 - Front Left
Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Input/output error
[1] states "Due to a legacy HW design problem", implying the issue applies to
all previous tegra-hda devices.
The tegra-hda device was introduced in tegra30 but only utilized in tegra124
until now.
For this reason it is unknown when this issue first manifested.
Applying the fix in [1] universally resolves this issue on tegra30.
Tested on the Ouya game console and the tf201 tablet.
[1] 60019d8c650d ("ALSA: hda/tegra: workaround playback failure on Tegra194")
This issue was never seen on Tegra210/Tegra186 and hence at that time it
was thought to be specific to Tegra194. I never tested this on Tegra30
since I don't have this device. I will clarify this with HW folks if
workaround is safer for all chips.
Signed-off-by: Peter Geis
Tested-by: Ion Agorria
---
sound/pci/hda/hda_tegra.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
index 70164d1428d4..f8d61e677a09 100644
--- a/sound/pci/hda/hda_tegra.c
+++ b/sound/pci/hda/hda_tegra.c
@@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx *chip, struct
platform_device *pdev)
* in powers of 2, next available ratio is 16 which can be
* used as a limiting factor here.
*/
- if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
- chip->bus.core.sdo_limit = 16;
+ chip->bus.core.sdo_limit = 16;
Future Tegra chips address this problem and hence cannot be enforced by
default. May be we can have like below:
if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
chip->bus.core.sdo_limit = 16;
/* codec detection */
if (!bus->codec_mask) {
--
2.25.1
Re: [External] Re: [PATCH 0/2] IdeaPad platform profile support
在 2021/1/5 上午5:58, Mark Pearson 写道: On 04/01/2021 15:58, Hans de Goede wrote: Hi, On 1/4/21 9:33 PM, Rafael J. Wysocki wrote: On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede wrote: Hi, On 1/1/21 1:56 PM, Jiaxun Yang wrote: Tested on Lenovo Yoga-14SARE Chinese Edition. [...] Just for my understanding of what happens nextplease correct me if I have anything wrong: - platform_profile gets pulled from ACPI for 5.11 - platform_profile gets updated to add this data/pointer implementation and goes into 5.12. Hi all, Another approach could be just let all the patch go through pdx86 tree and with pointer part acked by Rafael as it's unlikely to have merge conflicts. Jiaxun, let me know if you're happy with following up on that based on Hans suggestions, If you are pushed for time let me know and I'll happily help out/implement/test as required. I sadly don't have any ideapads but very happy to support your efforts any way I can. I'm happy with Hans suggestion, will send v2 for it later. I've been ask Lenovo engineers about DYTC and other ideapad ACPI stuff on Lenovo China forum[1], but moderator here told me Lenovo won't invest any Linux effort on their consumer product line :-( Is it possible to publish a DYTC specification or documents to help us further understand these mechanisms? I'm tired of reading disassembly AML and code to figure out these internals. - Can we get the x86 portion done at the same time or does that end up going to 5.13? I had been looking at the ideapad_laptop.c patch and have some concerns there as Jiaxun's patch is essentially a duplicate of what I implemented in thinkpad_acpi.c which doesn't seem to be ideal (especially as there is a V6 version of DYTC coming out this year). I haven't had time to look at code to consider better alternatives though... It may be worthy to share these code but I'm comfort to have this duplication as I'm unsure about the future of DYTC. Will DYTC for thinkpads always coherent with DYTC for ideapads? Thanks. [1]: https://club.lenovo.com.cn/thread-5980431-1-1.html - Jiaxun Mark
[PATCH 1/3] crypto: hisilicon - add ZIP device using mode parameter
Add 'uacce_mode' parameter for ZIP, which can be set as 0(default) or 1.
'0' means ZIP is only registered to kernel crypto, and '1' means it's
registered to both kernel crypto and UACCE.
Signed-off-by: Kai Ye
Reviewed-by: Zhou Wang
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/qm.c | 2 +-
drivers/crypto/hisilicon/qm.h | 27 +++
drivers/crypto/hisilicon/zip/zip_main.c | 14 ++
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index 10a04ab..904b99a 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -2206,7 +2206,7 @@ static int qm_alloc_uacce(struct hisi_qm *qm)
if (IS_ERR(uacce))
return PTR_ERR(uacce);
- if (uacce->flags & UACCE_DEV_SVA) {
+ if (uacce->flags & UACCE_DEV_SVA && qm->mode == UACCE_MODE_SVA) {
qm->use_sva = true;
} else {
/* only consider sva case */
diff --git a/drivers/crypto/hisilicon/qm.h b/drivers/crypto/hisilicon/qm.h
index 8624d12..c1dd0fc 100644
--- a/drivers/crypto/hisilicon/qm.h
+++ b/drivers/crypto/hisilicon/qm.h
@@ -85,6 +85,11 @@
/* page number for queue file region */
#define QM_DOORBELL_PAGE_NR1
+/* uacce mode of the driver */
+#define UACCE_MODE_NOUACCE 0 /* don't use uacce */
+#define UACCE_MODE_SVA 1 /* use uacce sva mode */
+#define UACCE_MODE_DESC"0(default) means only register to crypto, 1
means both register to crypto and uacce"
+
enum qm_stop_reason {
QM_NORMAL,
QM_SOFT_RESET,
@@ -249,6 +254,7 @@ struct hisi_qm {
resource_size_t phys_base;
resource_size_t phys_size;
struct uacce_device *uacce;
+ int mode;
};
struct hisi_qp_status {
@@ -333,6 +339,27 @@ static inline int vfs_num_set(const char *val, const
struct kernel_param *kp)
return param_set_int(val, kp);
}
+static inline int mode_set(const char *val, const struct kernel_param *kp)
+{
+ u32 n;
+ int ret;
+
+ if (!val)
+ return -EINVAL;
+
+ ret = kstrtou32(val, 10, );
+ if (ret != 0 || (n != UACCE_MODE_SVA &&
+n != UACCE_MODE_NOUACCE))
+ return -EINVAL;
+
+ return param_set_int(val, kp);
+}
+
+static inline int uacce_mode_set(const char *val, const struct kernel_param
*kp)
+{
+ return mode_set(val, kp);
+}
+
static inline void hisi_qm_init_list(struct hisi_qm_list *qm_list)
{
INIT_LIST_HEAD(_list->list);
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 4fb5a32b..9cdecff 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -211,6 +211,19 @@ static const struct debugfs_reg32 hzip_dfx_regs[] = {
{"HZIP_DECOMP_LZ77_CURR_ST ", 0x9cull},
};
+static const struct kernel_param_ops zip_uacce_mode_ops = {
+ .set = uacce_mode_set,
+ .get = param_get_int,
+};
+
+/*
+ * uacce_mode = 0 means zip only register to crypto,
+ * uacce_mode = 1 means zip both register to crypto and uacce.
+ */
+static u32 uacce_mode = UACCE_MODE_NOUACCE;
+module_param_cb(uacce_mode, _uacce_mode_ops, _mode, 0444);
+MODULE_PARM_DESC(uacce_mode, UACCE_MODE_DESC);
+
static int pf_q_num_set(const char *val, const struct kernel_param *kp)
{
return q_num_set(val, kp, PCI_DEVICE_ID_ZIP_PF);
@@ -752,6 +765,7 @@ static int hisi_zip_qm_init(struct hisi_qm *qm, struct
pci_dev *pdev)
qm->pdev = pdev;
qm->ver = pdev->revision;
qm->algs = "zlib\ngzip";
+ qm->mode = uacce_mode;
qm->sqe_size = HZIP_SQE_SIZE;
qm->dev_name = hisi_zip_name;
--
2.8.1
Re: linux-next: build warnings after merge of the net-next tree
Hi all,
On Mon, 21 Dec 2020 12:28:39 +1100 Stephen Rothwell
wrote:
>
> On Mon, 14 Dec 2020 20:10:25 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the net-next tree, today's linux-next build (htmldocs)
> > produced these warnings:
> >
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> > cfg80211_sar_chan_ranges - sar frequency ranges
> > on line 1759 - I thought it was a doc line
> > include/net/cfg80211.h:5073: warning: Function parameter or member
> > 'sar_capa' not described in 'wiphy'
> >
> > Introduced by commit
> >
> > 6bdb68cef7bf ("nl80211: add common API to configure SAR power
> > limitations")
>
> I am now getting these warnings from Linus' tree.
I am still getting these warnings ...
--
Cheers,
Stephen Rothwell
pgpGb3KarrMCE.pgp
Description: OpenPGP digital signature
[PATCH 2/3] crypto: hisilicon/hpre - register HPRE device to uacce
Register HPRE device to uacce framework for user space.
Signed-off-by: Kai Ye
Reviewed-by: Zhou Wang
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre_main.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index e5c9919..ad8b691 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "hpre.h"
#define HPRE_QUEUE_NUM_V2 1024
@@ -178,6 +179,19 @@ static const char *hpre_dfx_files[HPRE_DFX_FILE_NUM] = {
"invalid_req_cnt"
};
+static const struct kernel_param_ops hpre_uacce_mode_ops = {
+ .set = uacce_mode_set,
+ .get = param_get_int,
+};
+
+/*
+ * uacce_mode = 0 means hpre only register to crypto,
+ * uacce_mode = 1 means hpre both register to crypto and uacce.
+ */
+static u32 uacce_mode = UACCE_MODE_NOUACCE;
+module_param_cb(uacce_mode, _uacce_mode_ops, _mode, 0444);
+MODULE_PARM_DESC(uacce_mode, UACCE_MODE_DESC);
+
static int pf_q_num_set(const char *val, const struct kernel_param *kp)
{
return q_num_set(val, kp, HPRE_PCI_DEVICE_ID);
@@ -214,6 +228,30 @@ struct hisi_qp *hpre_create_qp(void)
return NULL;
}
+static void hpre_pasid_enable(struct hisi_qm *qm)
+{
+ u32 val;
+
+ val = readl_relaxed(qm->io_base + HPRE_DATA_RUSER_CFG);
+ val |= BIT(HPRE_PASID_EN_BIT);
+ writel_relaxed(val, qm->io_base + HPRE_DATA_RUSER_CFG);
+ val = readl_relaxed(qm->io_base + HPRE_DATA_WUSER_CFG);
+ val |= BIT(HPRE_PASID_EN_BIT);
+ writel_relaxed(val, qm->io_base + HPRE_DATA_WUSER_CFG);
+}
+
+static void hpre_pasid_disable(struct hisi_qm *qm)
+{
+ u32 val;
+
+ val = readl_relaxed(qm->io_base + HPRE_DATA_RUSER_CFG);
+ val &= ~BIT(HPRE_PASID_EN_BIT);
+ writel_relaxed(val, qm->io_base + HPRE_DATA_RUSER_CFG);
+ val = readl_relaxed(qm->io_base + HPRE_DATA_WUSER_CFG);
+ val &= ~BIT(HPRE_PASID_EN_BIT);
+ writel_relaxed(val, qm->io_base + HPRE_DATA_WUSER_CFG);
+}
+
static int hpre_cfg_by_dsm(struct hisi_qm *qm)
{
struct device *dev = >pdev->dev;
@@ -279,6 +317,10 @@ static int hpre_set_user_domain_and_cache(struct hisi_qm
*qm)
writel(0x0, HPRE_ADDR(qm, HPRE_COMM_CNT_CLR_CE));
writel(0x0, HPRE_ADDR(qm, HPRE_ECC_BYPASS));
+ /* Enable data buffer pasid */
+ if (qm->use_sva)
+ hpre_pasid_enable(qm);
+
writel(HPRE_BD_USR_MASK, HPRE_ADDR(qm, HPRE_BD_ARUSR_CFG));
writel(HPRE_BD_USR_MASK, HPRE_ADDR(qm, HPRE_BD_AWUSR_CFG));
writel(0x1, HPRE_ADDR(qm, HPRE_RDCHN_INI_CFG));
@@ -734,6 +776,8 @@ static int hpre_qm_init(struct hisi_qm *qm, struct pci_dev
*pdev)
return -EINVAL;
}
+ qm->algs = "rsa\ndh\n";
+ qm->mode = uacce_mode;
qm->pdev = pdev;
qm->ver = pdev->revision;
qm->sqe_size = HPRE_SQE_SIZE;
@@ -872,6 +916,14 @@ static int hpre_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto err_with_qm_start;
}
+ if (qm->uacce) {
+ ret = uacce_register(qm->uacce);
+ if (ret) {
+ pci_err(pdev, "failed to register uacce (%d)!\n", ret);
+ goto err_with_alg_register;
+ }
+ }
+
if (qm->fun_type == QM_HW_PF && vfs_num) {
ret = hisi_qm_sriov_enable(pdev, vfs_num);
if (ret < 0)
@@ -911,6 +963,8 @@ static void hpre_remove(struct pci_dev *pdev)
}
}
if (qm->fun_type == QM_HW_PF) {
+ if (qm->use_sva)
+ hpre_pasid_disable(qm);
hpre_cnt_regs_clear(qm);
qm->debug.curr_qm_qp_num = 0;
}
--
2.8.1
[PATCH 0/3] crypto: hisilicon - register device to uacce
1. Add parameter of UACCE mode selection for ZIP. 2. Register SEC and HPRE devices to UACCE framework for user space drivers. Kai Ye (3): crypto: hisilicon - add ZIP device using mode parameter crypto: hisilicon/hpre - register HPRE device to uacce crypto: hisilicon/sec - register SEC device to uacce drivers/crypto/hisilicon/hpre/hpre_main.c | 54 +++ drivers/crypto/hisilicon/qm.c | 2 +- drivers/crypto/hisilicon/qm.h | 27 drivers/crypto/hisilicon/sec2/sec_main.c | 39 +- drivers/crypto/hisilicon/zip/zip_main.c | 14 5 files changed, 134 insertions(+), 2 deletions(-) -- 2.8.1
[PATCH 3/3] crypto: hisilicon/sec - register SEC device to uacce
Register SEC device to uacce framework for user space.
Signed-off-by: Kai Ye
Reviewed-by: Zhou Wang
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/sec2/sec_main.c | 39 +++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/sec2/sec_main.c
b/drivers/crypto/hisilicon/sec2/sec_main.c
index b35c1c2..4809c19 100644
--- a/drivers/crypto/hisilicon/sec2/sec_main.c
+++ b/drivers/crypto/hisilicon/sec2/sec_main.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "sec.h"
@@ -74,6 +75,16 @@
#define SEC_USER0_SMMU_NORMAL (BIT(23) | BIT(15))
#define SEC_USER1_SMMU_NORMAL (BIT(31) | BIT(23) | BIT(15) | BIT(7))
+#define SEC_USER1_ENABLE_CONTEXT_SSV BIT(24)
+#define SEC_USER1_ENABLE_DATA_SSV BIT(16)
+#define SEC_USER1_WB_CONTEXT_SSV BIT(8)
+#define SEC_USER1_WB_DATA_SSV BIT(0)
+#define SEC_USER1_SVA_SET (SEC_USER1_ENABLE_CONTEXT_SSV | \
+ SEC_USER1_ENABLE_DATA_SSV | \
+ SEC_USER1_WB_CONTEXT_SSV | \
+ SEC_USER1_WB_DATA_SSV)
+#define SEC_USER1_SMMU_SVA (SEC_USER1_SMMU_NORMAL |
SEC_USER1_SVA_SET)
+#define SEC_USER1_SMMU_MASK(~SEC_USER1_SVA_SET)
#define SEC_CORE_INT_STATUS_M_ECC BIT(2)
#define SEC_DELAY_10_US10
@@ -233,6 +244,18 @@ struct hisi_qp **sec_create_qps(void)
return NULL;
}
+static const struct kernel_param_ops sec_uacce_mode_ops = {
+ .set = uacce_mode_set,
+ .get = param_get_int,
+};
+
+/*
+ * uacce_mode = 0 means sec only register to crypto,
+ * uacce_mode = 1 means sec both register to crypto and uacce.
+ */
+static u32 uacce_mode = UACCE_MODE_NOUACCE;
+module_param_cb(uacce_mode, _uacce_mode_ops, _mode, 0444);
+MODULE_PARM_DESC(uacce_mode, UACCE_MODE_DESC);
static const struct pci_device_id sec_dev_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_HUAWEI, SEC_PF_PCI_DEVICE_ID) },
@@ -299,7 +322,11 @@ static int sec_engine_init(struct hisi_qm *qm)
writel_relaxed(reg, SEC_ADDR(qm, SEC_INTERFACE_USER_CTRL0_REG));
reg = readl_relaxed(SEC_ADDR(qm, SEC_INTERFACE_USER_CTRL1_REG));
- reg |= SEC_USER1_SMMU_NORMAL;
+ reg &= SEC_USER1_SMMU_MASK;
+ if (qm->use_sva)
+ reg |= SEC_USER1_SMMU_SVA;
+ else
+ reg |= SEC_USER1_SMMU_NORMAL;
writel_relaxed(reg, SEC_ADDR(qm, SEC_INTERFACE_USER_CTRL1_REG));
writel(SEC_SINGLE_PORT_MAX_TRANS,
@@ -758,6 +785,8 @@ static int sec_qm_init(struct hisi_qm *qm, struct pci_dev
*pdev)
qm->pdev = pdev;
qm->ver = pdev->revision;
+ qm->algs = "cipher\ndigest\naead\n";
+ qm->mode = uacce_mode;
qm->sqe_size = SEC_SQE_SIZE;
qm->dev_name = sec_name;
@@ -885,6 +914,14 @@ static int sec_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
goto err_qm_stop;
}
+ if (qm->uacce) {
+ ret = uacce_register(qm->uacce);
+ if (ret) {
+ pci_err(pdev, "failed to register uacce (%d)!\n", ret);
+ goto err_alg_unregister;
+ }
+ }
+
if (qm->fun_type == QM_HW_PF && vfs_num) {
ret = hisi_qm_sriov_enable(pdev, vfs_num);
if (ret < 0)
--
2.8.1
Re: [PATCH v3 1/2] dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings
On 04-01-21, 12:37, Bjorn Andersson wrote: > > > +properties: > > > + compatible: > > > +const: qcom,sm8350-pinctrl > > > > If this block is called TLMM, then I'd expect that to be in the > > compatible string. But I guess this is consistent with the others. > > > > This is my mistake 7 years ago and it bothers me every time we write a > new one of these - in particular since we now support a few different > "Qualcomm pinctrl" blocks. > > It would be ugly for a while, but I'm in favor of naming these > "qcom,-tlmm" going forward. > > PS. And we can solve the ugliness by introducing the "proper" naming > (and keeping the old one for backwards compatibility) as we migrate the > binding documents to yaml. Okay I will update this one to qcom,sm8350-tlmm. Also we use sm8350_pinctrl few places in the driver, will update that to sm8350_tlmm as well Thanks -- ~Vinod
[PATCH] crypto: hisilicon/qm - SVA bugfixed on Kunpeng920
Kunpeng920 SEC/HPRE/ZIP cannot support running user space SVA and kernel
Crypto at the same time. Therefore, the algorithms should not be registered
to Crypto as user space SVA is enabled.
Signed-off-by: Kai Ye
Reviewed-by: Zaibo Xu
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/qm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index f21ccae..10a04ab 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -4004,6 +4004,9 @@ int hisi_qm_alg_register(struct hisi_qm *qm, struct
hisi_qm_list *qm_list)
{
int flag = 0;
int ret = 0;
+ /* HW V2 not support both use uacce sva mode and hardware crypto algs */
+ if (qm->ver <= QM_HW_V2 && qm->use_sva)
+ return 0;
mutex_lock(_list->lock);
if (list_empty(_list->list))
@@ -4035,6 +4038,9 @@ EXPORT_SYMBOL_GPL(hisi_qm_alg_register);
*/
void hisi_qm_alg_unregister(struct hisi_qm *qm, struct hisi_qm_list *qm_list)
{
+ if (qm->ver <= QM_HW_V2 && qm->use_sva)
+ return;
+
mutex_lock(_list->lock);
list_del(>list);
mutex_unlock(_list->lock);
--
2.8.1
Re: [External] Re: [PATCH 3/6] mm: hugetlb: fix a race between freeing and dissolving the page
On Tue, Jan 5, 2021 at 8:02 AM Mike Kravetz wrote:
>
> On 1/3/21 10:58 PM, Muchun Song wrote:
> > There is a race condition between __free_huge_page()
> > and dissolve_free_huge_page().
> >
> > CPU0: CPU1:
> >
> > // page_count(page) == 1
> > put_page(page)
> > __free_huge_page(page)
> > dissolve_free_huge_page(page)
> > spin_lock(_lock)
> > // PageHuge(page) && !page_count(page)
> > update_and_free_page(page)
> > // page is freed to the buddy
> > spin_unlock(_lock)
> > spin_lock(_lock)
> > clear_page_huge_active(page)
> > enqueue_huge_page(page)
> > // It is wrong, the page is already freed
> > spin_unlock(_lock)
> >
> > The race windows is between put_page() and spin_lock() which
> > is in the __free_huge_page().
> >
> > We should make sure that the page is already on the free list
> > when it is dissolved.
> >
> > Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle
> > hugepage")
> > Signed-off-by: Muchun Song
> > ---
> > mm/hugetlb.c | 48
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 1f3bf1710b66..72608008f8b4 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -79,6 +79,21 @@ DEFINE_SPINLOCK(hugetlb_lock);
> > static int num_fault_mutexes;
> > struct mutex *hugetlb_fault_mutex_table cacheline_aligned_in_smp;
> >
> > +static inline bool PageHugeFreed(struct page *head)
> > +{
> > + return page_private(head) == -1UL;
>
> return page_private(head + 4) == -1UL;
Very thanks. It's my mistake when rebasing. Will
update in the next version.
>
> > +}
> > +
> > +static inline void SetPageHugeFreed(struct page *head)
> > +{
> > + set_page_private(head + 4, -1UL);
> > +}
> > +
> > +static inline void ClearPageHugeFreed(struct page *head)
> > +{
> > + set_page_private(head + 4, 0);
> > +}
>
> It is unfortunate that we can not use some existing value like
> page_huge_active() to determine if dissolve_free_huge_page() should
> proceed with freeing the page to buddy. If the existing check,
>
> if (!page_count(page)) {
>
> was changed to
>
> if (!page_count(page) && !page_huge_active(page)) {
>
> the race window would be shrunk. However, the most straight forward
> way to fully close the window is with the approach taken here.
>
> > +
> > /* Forward declaration */
> > static int hugetlb_acct_memory(struct hstate *h, long delta);
> >
> > @@ -1028,6 +1043,7 @@ static void enqueue_huge_page(struct hstate *h,
> > struct page *page)
> > list_move(>lru, >hugepage_freelists[nid]);
> > h->free_huge_pages++;
> > h->free_huge_pages_node[nid]++;
> > + SetPageHugeFreed(page);
> > }
> >
> > static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid)
> > @@ -1044,6 +1060,7 @@ static struct page
> > *dequeue_huge_page_node_exact(struct hstate *h, int nid)
> >
> > list_move(>lru, >hugepage_activelist);
> > set_page_refcounted(page);
> > + ClearPageHugeFreed(page);
> > h->free_huge_pages--;
> > h->free_huge_pages_node[nid]--;
> > return page;
> > @@ -1504,6 +1521,7 @@ static void prep_new_huge_page(struct hstate *h,
> > struct page *page, int nid)
> > spin_lock(_lock);
> > h->nr_huge_pages++;
> > h->nr_huge_pages_node[nid]++;
> > + ClearPageHugeFreed(page);
> > spin_unlock(_lock);
> > }
> >
> > @@ -1770,6 +1788,36 @@ int dissolve_free_huge_page(struct page *page)
> > int nid = page_to_nid(head);
> > if (h->free_huge_pages - h->resv_huge_pages == 0)
> > goto out;
> > +
> > + /*
> > + * There is a race condition between __free_huge_page()
> > + * and dissolve_free_huge_page().
> > + *
> > + * CPU0: CPU1:
> > + *
> > + * // page_count(page) == 1
> > + * put_page(page)
> > + * __free_huge_page(page)
> > + * dissolve_free_huge_page(page)
> > + * spin_lock(_lock)
> > + * // PageHuge(page) &&
> > !page_count(page)
> > + * update_and_free_page(page)
> > + * // page is freed to the
> > buddy
> > + * spin_unlock(_lock)
> > + * spin_lock(_lock)
> > + * enqueue_huge_page(page)
> > + * // It is wrong, the page is already freed
> > + * spin_unlock(_lock)
> > +
Re: [PATCH 5.4 00/47] 5.4.87-rc1 review
Hello! On 1/4/21 9:56 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.4.87 release. There are 47 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 Wed, 06 Jan 2021 15:56:52 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.87-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-5.4.y and the diffstat can be found below. thanks, greg k-h Results from Linaro’s test farm. No regressions detected. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.87-rc1 git repo: ['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc'] git branch: linux-5.4.y git commit: 01678c93fa9e3da85a53deb1510c25fdcd2e5d6d git describe: v5.4.86-48-g01678c93fa9e Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.86-48-g01678c93fa9e No regressions (compared to build v5.4.86) No fixes (compared to build v5.4.86) Ran 48522 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan Test Suites --- * build * fwts * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fs-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * rcutorture * v4l2-compliance Greetings! Daniel Díaz daniel.d...@linaro.org -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.10 00/63] 5.10.5-rc1 review
Hello! On 1/4/21 9:56 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.10.5 release. There are 63 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 Wed, 06 Jan 2021 15:56:52 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.5-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-5.10.y and the diffstat can be found below. thanks, greg k-h Results from Linaro’s test farm. No regressions detected. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.10.5-rc1 git repo: ['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc'] git branch: linux-5.10.y git commit: 18347c4f07814f2fef15f3b1518b6b8a88bae75a git describe: v5.10.4-64-g18347c4f0781 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.4-64-g18347c4f0781 No regressions (compared to build v5.10.4) No fixes (compared to build v5.10.4) Ran 53801 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-i386-clang - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan Test Suites --- * build * fwts * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none * kunit * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fs-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * rcutorture * v4l2-compliance Greetings! Daniel Díaz daniel.d...@linaro.org -- Linaro LKFT https://lkft.linaro.org
Re: [f2fs-dev] [PATCH v2] f2fs: fix null page reference in redirty_blocks
On 2021/1/5 12:16, Daeho Jeong wrote:
From: Daeho Jeong
Fixed null page reference when find_lock_page() fails in
redirty_blocks().
Signed-off-by: Daeho Jeong
Reported-by: Colin Ian King
Fixes: 5fdb322ff2c2 ("f2fs: add F2FS_IOC_DECOMPRESS_FILE and
F2FS_IOC_COMPRESS_FILE")
Reviewed-by: Chao Yu
Thanks,
Re: [PATCH 1/2] rtc: pcf2127: Disable Power-On Reset Override
Hi Philipp,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on v5.11-rc2 next-20210104]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Philipp-Rosenberger/rtc-pcf2127-proper-initilize-rtc-after-power-loss/20210105-002256
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git
rtc-next
config: parisc-randconfig-r006-20210105 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/ac3cb31420b7b402d9deda24768725e3b956ccf5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Philipp-Rosenberger/rtc-pcf2127-proper-initilize-rtc-after-power-loss/20210105-002256
git checkout ac3cb31420b7b402d9deda24768725e3b956ccf5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=parisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/rtc/rtc-pcf2127.c: In function 'pcf2127_probe':
>> drivers/rtc/rtc-pcf2127.c:622:5: error: 'PCF2127_BIT_CTRL1_POR_OVRD'
>> undeclared (first use in this function); did you mean
>> 'PCF2127_BIT_CTRL1_TSF1'?
622 | PCF2127_BIT_CTRL1_POR_OVRD);
| ^~
| PCF2127_BIT_CTRL1_TSF1
drivers/rtc/rtc-pcf2127.c:622:5: note: each undeclared identifier is
reported only once for each function it appears in
vim +622 drivers/rtc/rtc-pcf2127.c
561
562 static int pcf2127_probe(struct device *dev, struct regmap *regmap,
563 int alarm_irq, const char *name, bool
has_nvmem)
564 {
565 struct pcf2127 *pcf2127;
566 int ret = 0;
567
568 dev_dbg(dev, "%s\n", __func__);
569
570 pcf2127 = devm_kzalloc(dev, sizeof(*pcf2127), GFP_KERNEL);
571 if (!pcf2127)
572 return -ENOMEM;
573
574 pcf2127->regmap = regmap;
575
576 dev_set_drvdata(dev, pcf2127);
577
578 pcf2127->rtc = devm_rtc_allocate_device(dev);
579 if (IS_ERR(pcf2127->rtc))
580 return PTR_ERR(pcf2127->rtc);
581
582 pcf2127->rtc->ops = _rtc_ops;
583 pcf2127->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
584 pcf2127->rtc->range_max = RTC_TIMESTAMP_END_2099;
585 pcf2127->rtc->set_start_time = true; /* Sets actual start to
1970 */
586 pcf2127->rtc->uie_unsupported = 1;
587
588 if (alarm_irq > 0) {
589 ret = devm_request_threaded_irq(dev, alarm_irq, NULL,
590 pcf2127_rtc_irq,
591 IRQF_TRIGGER_LOW |
IRQF_ONESHOT,
592 dev_name(dev), dev);
593 if (ret) {
594 dev_err(dev, "failed to request alarm irq\n");
595 return ret;
596 }
597 }
598
599 if (alarm_irq > 0 || device_property_read_bool(dev,
"wakeup-source")) {
600 device_init_wakeup(dev, true);
601 pcf2127->rtc->ops = _rtc_alrm_ops;
602 }
603
604 if (has_nvmem) {
605 struct nvmem_config nvmem_cfg = {
606 .priv = pcf2127,
607 .reg_read = pcf2127_nvmem_read,
608 .reg_write = pcf2127_nvmem_write,
609 .size = 512,
610 };
611
612 ret = devm_rtc_nvmem_register(pcf2127->rtc, _cfg);
613 }
614
615 /*
616 * Disable the Power-On Reset Override facility to start normal
617 * operation. If the operation should fail, just move on. The
RTC should
618 * work fine, but functions like watchdog and alarm interrupts
might
619 * not work.
620 */
621 ret = regmap_clear_bits(pcf2127->regmap, PCF2127_REG_CTRL1,
> 622 PCF2127_BIT_CTRL1_POR_OVRD);
623 if (ret) {
624 dev_err(dev, "%s: can't disable PORO (ctrl1).\n",
__func
[PATCH] ubifs: Fix memleak in ubifs_init_authentication
When crypto_shash_digestsize() fails, c->hmac_tfm
has not been freed before returning, which leads
to memleak.
Fixes: 49525e5eecca5 ("ubifs: Add helper functions for authentication support")
Signed-off-by: Dinghao Liu
---
fs/ubifs/auth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/auth.c b/fs/ubifs/auth.c
index 51a7c8c2c3f0..e564d5ff8781 100644
--- a/fs/ubifs/auth.c
+++ b/fs/ubifs/auth.c
@@ -327,7 +327,7 @@ int ubifs_init_authentication(struct ubifs_info *c)
ubifs_err(c, "hmac %s is bigger than maximum allowed hmac size
(%d > %d)",
hmac_name, c->hmac_desc_len, UBIFS_HMAC_ARR_SZ);
err = -EINVAL;
- goto out_free_hash;
+ goto out_free_hmac;
}
err = crypto_shash_setkey(c->hmac_tfm, ukp->data, ukp->datalen);
--
2.17.1
Re: [PATCH v3 -next] staging: vc04_services: use DEFINE_MUTEX() for mutex lock
On Tue, Jan 05, 2021 at 10:05:47AM +0800, Zheng Yongjun wrote:
> mutex lock can be initialized automatically with DEFINE_MUTEX()
> rather than explicitly calling mutex_init().
>
> Signed-off-by: Zheng Yongjun
> ---
> .../vc04_services/interface/vchiq_arm/vchiq_connected.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git
> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
> index 79b75efa6868..938307f39b9c 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_connected.c
> @@ -12,15 +12,13 @@ static intg_connected;
> static intg_num_deferred_callbacks;
> static VCHIQ_CONNECTED_CALLBACK_T g_deferred_callback[MAX_CALLBACKS];
> static intg_once_init;
> -static struct mutex g_connected_mutex;
> +static DEFINE_MUTEX(g_connected_mutex);
>
> /* Function to initialize our lock */
> static void connected_init(void)
> {
> - if (!g_once_init) {
> - mutex_init(_connected_mutex);
> + if (!g_once_init)
> g_once_init = 1;
> - }
Why do you still need g_once_init now?
Re: [PATCH v2] drivers core: Free dma_range_map when driver probe failed
On Tue, Jan 05, 2021 at 01:41:48PM +0800, meng...@windriver.com wrote: > From: Limeng This does not match your signed-off-by line :(
Re: [PATCH v4] proc: Allow pid_revalidate() during LOOKUP_RCU
On Mon, Jan 04, 2021 at 03:21:22PM -0800, Stephen Brennan wrote:
> The pid_revalidate() function drops from RCU into REF lookup mode. When
> many threads are resolving paths within /proc in parallel, this can
> result in heavy spinlock contention on d_lockref as each thread tries to
> grab a reference to the /proc dentry (and drop it shortly thereafter).
>
> Investigation indicates that it is not necessary to drop RCU in
> pid_revalidate(), as no RCU data is modified and the function never
> sleeps. So, remove the LOOKUP_RCU check.
Umm... I'm rather worried about the side effect you are removing here -
you are suddenly exposing a bunch of methods in there to RCU mode.
E.g. is proc_pid_permission() safe with MAY_NOT_BLOCK in the mask?
generic_permission() call in there is fine, but has_pid_permission()
doesn't even see the mask. Is that thing safe in RCU mode? AFAICS,
this
static int selinux_ptrace_access_check(struct task_struct *child,
unsigned int mode)
{
u32 sid = current_sid();
u32 csid = task_sid(child);
if (mode & PTRACE_MODE_READ)
return avc_has_perm(_state,
sid, csid, SECCLASS_FILE, FILE__READ, NULL);
return avc_has_perm(_state,
sid, csid, SECCLASS_PROCESS, PROCESS__PTRACE, NULL);
}
is reachable and IIRC avc_has_perm() should *NOT* be called in RCU mode.
If nothing else, audit handling needs care...
And LSM-related stuff is only a part of possible issues here. It does need
a careful code audit - you are taking a bunch of methods into the conditions
they'd never been tested in. ->permission(), ->get_link(), ->d_revalidate(),
->d_hash() and ->d_compare() instances for objects that subtree. The last
two are not there in case of anything in /proc/, but the first 3 very
much are.
Re: [PATCH -next] tpm: Use kzalloc for allocating only one thing
On Tue, Dec 29, 2020 at 08:23:49AM -0800, James Bottomley wrote:
> On Tue, 2020-12-29 at 21:51 +0800, Zheng Yongjun wrote:
> > Use kzalloc rather than kcalloc(1,...)
> >
> > The semantic patch that makes this change is as follows:
> > (http://coccinelle.lip6.fr/)
>
> What's the reason for wanting to do this transformation?
>
> > drivers/char/tpm/tpm1-cmd.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-
> > cmd.c
> > index ca7158fa6e6c..4d8415e3b778 100644
> > --- a/drivers/char/tpm/tpm1-cmd.c
> > +++ b/drivers/char/tpm/tpm1-cmd.c
> > @@ -794,7 +794,7 @@ int tpm1_pm_suspend(struct tpm_chip *chip, u32
> > tpm_suspend_pcr)
> > */
> > int tpm1_get_pcr_allocation(struct tpm_chip *chip)
> > {
> > - chip->allocated_banks = kcalloc(1, sizeof(*chip-
> > >allocated_banks),
> > + chip->allocated_banks = kzalloc(sizeof(*chip->allocated_banks),
> > GFP_KERNEL);
> > if (!chip->allocated_banks)
> > return -ENOMEM;
>
> The reason tpm1 has this is because it mirrors the allocation in tpm2
> so we retain code consistency. It's a fairly minor advantage, so it
> could be changed if you have a better rationale ... but what is it?
Yup, I neither understand this.
> James
/Jarkko
RE: [PATCH v3 2/3] iommu/vt-d: Track device aux-attach with subdevice_domain_info
Hi Baolu,
> From: Lu Baolu
> Sent: Tuesday, December 29, 2020 4:38 PM
>
> Hi Yi,
>
> On 2020/12/29 11:25, Liu Yi L wrote:
> > In the existing code, loop all devices attached to a domain does not
> > include sub-devices attached via iommu_aux_attach_device().
> >
> > This was found by when I'm working on the belwo patch, There is no
> ^
> below
nice catch.
> > device in the domain->devices list, thus unable to get the cap and
> > ecap of iommu unit. But this domain actually has subdevice which is
> > attached via aux-manner. But it is tracked by domain. This patch is
> > going to fix it.
> >
> > https://lore.kernel.org/kvm/1599734733-6431-17-git-send-email-
> yi.l@intel.com/
> >
> > And this fix goes beyond the patch above, such sub-device tracking is
> > necessary for other cases. For example, flushing device_iotlb for a
> > domain which has sub-devices attached by auxiliary manner.
> >
> > Co-developed-by: Xin Zeng
> > Signed-off-by: Xin Zeng
> > Signed-off-by: Liu Yi L
>
> Others look good to me.
>
> Fixes: 67b8e02b5e761 ("iommu/vt-d: Aux-domain specific domain
> attach/detach")
> Acked-by: Lu Baolu
thanks,
Regards,
Yi Liu
> Best regards,
> baolu
>
> > ---
> > drivers/iommu/intel/iommu.c | 95 +++
> --
> > include/linux/intel-iommu.h | 16 +--
> > 2 files changed, 82 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> > index 788119c5b021..d7720a836268 100644
> > --- a/drivers/iommu/intel/iommu.c
> > +++ b/drivers/iommu/intel/iommu.c
> > @@ -1877,6 +1877,7 @@ static struct dmar_domain *alloc_domain(int
> flags)
> > domain->flags |= DOMAIN_FLAG_USE_FIRST_LEVEL;
> > domain->has_iotlb_device = false;
> > INIT_LIST_HEAD(>devices);
> > + INIT_LIST_HEAD(>subdevices);
> >
> > return domain;
> > }
> > @@ -2547,7 +2548,7 @@ static struct dmar_domain
> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
> > info->iommu = iommu;
> > info->pasid_table = NULL;
> > info->auxd_enabled = 0;
> > - INIT_LIST_HEAD(>auxiliary_domains);
> > + INIT_LIST_HEAD(>subdevices);
> >
> > if (dev && dev_is_pci(dev)) {
> > struct pci_dev *pdev = to_pci_dev(info->dev);
> > @@ -4475,33 +4476,61 @@ is_aux_domain(struct device *dev, struct
> iommu_domain *domain)
> > domain->type == IOMMU_DOMAIN_UNMANAGED;
> > }
> >
> > -static void auxiliary_link_device(struct dmar_domain *domain,
> > - struct device *dev)
> > +static inline struct subdev_domain_info *
> > +lookup_subdev_info(struct dmar_domain *domain, struct device *dev)
> > +{
> > + struct subdev_domain_info *sinfo;
> > +
> > + if (!list_empty(>subdevices)) {
> > + list_for_each_entry(sinfo, >subdevices,
> link_domain) {
> > + if (sinfo->pdev == dev)
> > + return sinfo;
> > + }
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +static int auxiliary_link_device(struct dmar_domain *domain,
> > +struct device *dev)
> > {
> > struct device_domain_info *info = get_domain_info(dev);
> > + struct subdev_domain_info *sinfo = lookup_subdev_info(domain,
> dev);
> >
> > assert_spin_locked(_domain_lock);
> > if (WARN_ON(!info))
> > - return;
> > + return -EINVAL;
> > +
> > + if (!sinfo) {
> > + sinfo = kzalloc(sizeof(*sinfo), GFP_ATOMIC);
> > + sinfo->domain = domain;
> > + sinfo->pdev = dev;
> > + list_add(>link_phys, >subdevices);
> > + list_add(>link_domain, >subdevices);
> > + }
> >
> > - domain->auxd_refcnt++;
> > - list_add(>auxd, >auxiliary_domains);
> > + return ++sinfo->users;
> > }
> >
> > -static void auxiliary_unlink_device(struct dmar_domain *domain,
> > - struct device *dev)
> > +static int auxiliary_unlink_device(struct dmar_domain *domain,
> > + struct device *dev)
> > {
> > struct device_domain_info *info = get_domain_info(dev);
> > + struct subdev_domain_info *sinfo = lookup_subdev_info(domain,
> dev);
> > + int ret;
> >
> > assert_spin_locked(_domain_lock);
> > - if (WARN_ON(!info))
> > - return;
> > + if (WARN_ON(!info || !sinfo || sinfo->users <= 0))
> > + return -EINVAL;
> >
> > - list_del(>auxd);
> > - domain->auxd_refcnt--;
> > + ret = --sinfo->users;
> > + if (!ret) {
> > + list_del(>link_phys);
> > + list_del(>link_domain);
> > + kfree(sinfo);
> > + }
> >
> > - if (!domain->auxd_refcnt && domain->default_pasid > 0)
> > - ioasid_put(domain->default_pasid);
> > + return ret;
> > }
> >
> > static int aux_domain_add_dev(struct dmar_domain *domain,
> > @@ -4530,6 +4559,19 @@ static int aux_domain_add_dev(struct
> dmar_domain *domain,
> > }
> >
> >
Re: [RFC v3 1/2] vfio/platform: add support for msi
On Tue, Dec 22, 2020 at 10:57 PM Auger Eric wrote:
>
> Hi Vikas,
>
> On 12/14/20 6:45 PM, Vikas Gupta wrote:
> > MSI support for platform devices.The MSI block
> > is added as an extended IRQ which exports caps
> > VFIO_IRQ_INFO_CAP_TYPE and VFIO_IRQ_INFO_CAP_MSI_DESCS.
> >
> > Signed-off-by: Vikas Gupta
> > ---
> > drivers/vfio/platform/vfio_platform_common.c | 179 +++-
> > drivers/vfio/platform/vfio_platform_irq.c | 260 +-
> > drivers/vfio/platform/vfio_platform_private.h | 32 +++
> > include/uapi/linux/vfio.h | 44 +++
> > 4 files changed, 496 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/vfio/platform/vfio_platform_common.c
> > b/drivers/vfio/platform/vfio_platform_common.c
> > index fb4b385191f2..c936852f35d7 100644
> > --- a/drivers/vfio/platform/vfio_platform_common.c
> > +++ b/drivers/vfio/platform/vfio_platform_common.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "vfio_platform_private.h"
> >
> > @@ -26,6 +27,8 @@
> > #define VFIO_PLATFORM_IS_ACPI(vdev) ((vdev)->acpihid != NULL)
> >
> > static LIST_HEAD(reset_list);
> > +/* devices having MSI support */
> nit: for devices using MSIs?
> > +static LIST_HEAD(msi_list);
> > static DEFINE_MUTEX(driver_lock);
> >
> > static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char
> > *compat,
> > @@ -47,6 +50,25 @@ static vfio_platform_reset_fn_t
> > vfio_platform_lookup_reset(const char *compat,
> > return reset_fn;
> > }
> >
> > +static bool vfio_platform_lookup_msi(struct vfio_platform_device *vdev)
> > +{
> > + bool has_msi = false;
> > + struct vfio_platform_msi_node *iter;
> > +
> > + mutex_lock(_lock);
> > + list_for_each_entry(iter, _list, link) {
> > + if (!strcmp(iter->compat, vdev->compat) &&
> > + try_module_get(iter->owner)) {
> > + vdev->msi_module = iter->owner;
> > + vdev->of_get_msi = iter->of_get_msi;
> > + has_msi = true;
> > + break;
> > + }
> > + }
> > + mutex_unlock(_lock);
> > + return has_msi;
> > +}
> > +
> > static int vfio_platform_acpi_probe(struct vfio_platform_device *vdev,
> > struct device *dev)
> > {
> > @@ -126,6 +148,19 @@ static int vfio_platform_get_reset(struct
> > vfio_platform_device *vdev)
> > return vdev->of_reset ? 0 : -ENOENT;
> > }
> >
> > +static int vfio_platform_get_msi(struct vfio_platform_device *vdev)
> > +{
> > + bool has_msi;
> > +
> > + has_msi = vfio_platform_lookup_msi(vdev);
> > + if (!has_msi) {
> > + request_module("vfio-msi:%s", vdev->compat);
> > + has_msi = vfio_platform_lookup_msi(vdev);
> > + }
> > +
> > + return has_msi ? 0 : -ENOENT;
> > +}
> > +
> > static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
> > {
> > if (VFIO_PLATFORM_IS_ACPI(vdev))
> > @@ -135,6 +170,12 @@ static void vfio_platform_put_reset(struct
> > vfio_platform_device *vdev)
> > module_put(vdev->reset_module);
> > }
> >
> > +static void vfio_platform_put_msi(struct vfio_platform_device *vdev)
> > +{
> > + if (vdev->of_get_msi)
> > + module_put(vdev->msi_module);
> > +}
> > +
> > static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
> > {
> > int cnt = 0, i;
> > @@ -343,9 +384,17 @@ static long vfio_platform_ioctl(void *device_data,
> >
> > } else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
> > struct vfio_irq_info info;
> > + struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
> > + struct vfio_irq_info_cap_msi *msi_info = NULL;
> > + int ext_irq_index = vdev->num_irqs - vdev->num_ext_irqs;
> > + unsigned long capsz;
> > + u32 index;
> >
> > minsz = offsetofend(struct vfio_irq_info, count);
> >
> > + /* For backward compatibility, cannot require this */
> > + capsz = offsetofend(struct vfio_irq_info, cap_offset);
> > +
> > if (copy_from_user(, (void __user *)arg, minsz))
> > return -EFAULT;
> >
> > @@ -355,8 +404,94 @@ static long vfio_platform_ioctl(void *device_data,
> > if (info.index >= vdev->num_irqs)
> > return -EINVAL;
> >
> > - info.flags = vdev->irqs[info.index].flags;
> > - info.count = vdev->irqs[info.index].count;
> > + if (info.argsz >= capsz)
> > + minsz = capsz;
> > +
> > + index = info.index;
> > +
> > + info.flags = vdev->irqs[index].flags;
> > + info.count = vdev->irqs[index].count;
> > +
> > + if (ext_irq_index - index == VFIO_EXT_IRQ_MSI) {
> > + struct vfio_irq_info_cap_type cap_type = {
> > + .header.id =
Re: [PATCH] net: qrtr: fix null-ptr-deref in qrtr_ns_remove
I sent a v2 on this one because of the redundant braces in
qrtr_proto_init, sorry for the noise.
在 2021/1/5 10:40, Qinglang Miao 写道:
A null-ptr-deref bug is reported by Hulk Robot like this:
--
KASAN: null-ptr-deref in range [0x0128-0x012f]
Call Trace:
qrtr_ns_remove+0x22/0x40 [ns]
qrtr_proto_fini+0xa/0x31 [qrtr]
__x64_sys_delete_module+0x337/0x4e0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x468ded
--
When qrtr_ns_init fails in qrtr_proto_init, qrtr_ns_remove which would
be called later on would raise a null-ptr-deref because qrtr_ns.workqueue
has been destroyed.
Fix it by making qrtr_ns_init have a return value and adding a check in
qrtr_proto_init.
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
net/qrtr/ns.c | 7 ---
net/qrtr/qrtr.c | 14 +++---
net/qrtr/qrtr.h | 2 +-
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index 56aaf8cb6..8d00dfe81 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -755,7 +755,7 @@ static void qrtr_ns_data_ready(struct sock *sk)
queue_work(qrtr_ns.workqueue, _ns.work);
}
-void qrtr_ns_init(void)
+int qrtr_ns_init(void)
{
struct sockaddr_qrtr sq;
int ret;
@@ -766,7 +766,7 @@ void qrtr_ns_init(void)
ret = sock_create_kern(_net, AF_QIPCRTR, SOCK_DGRAM,
PF_QIPCRTR, _ns.sock);
if (ret < 0)
- return;
+ return ret;
ret = kernel_getsockname(qrtr_ns.sock, (struct sockaddr *));
if (ret < 0) {
@@ -797,12 +797,13 @@ void qrtr_ns_init(void)
if (ret < 0)
goto err_wq;
- return;
+ return 0;
err_wq:
destroy_workqueue(qrtr_ns.workqueue);
err_sock:
sock_release(qrtr_ns.sock);
+ return ret;
}
EXPORT_SYMBOL_GPL(qrtr_ns_init);
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index f4ab3ca6d..95533e451 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -1288,12 +1288,20 @@ static int __init qrtr_proto_init(void)
rc = sock_register(_family);
if (rc) {
- proto_unregister(_proto);
- return rc;
+ goto err_proto;
}
- qrtr_ns_init();
+ rc = qrtr_ns_init();
+ if (rc) {
+ goto err_sock;
+ } >
+ return 0;
+
+err_sock:
+ sock_unregister(qrtr_family.family);
+err_proto:
+ proto_unregister(_proto);
return rc;
}
postcore_initcall(qrtr_proto_init);
diff --git a/net/qrtr/qrtr.h b/net/qrtr/qrtr.h
index dc2b67f17..3f2d28696 100644
--- a/net/qrtr/qrtr.h
+++ b/net/qrtr/qrtr.h
@@ -29,7 +29,7 @@ void qrtr_endpoint_unregister(struct qrtr_endpoint *ep);
int qrtr_endpoint_post(struct qrtr_endpoint *ep, const void *data, size_t len);
-void qrtr_ns_init(void);
+int qrtr_ns_init(void);
void qrtr_ns_remove(void);
[PATCH v2] net: qrtr: fix null-ptr-deref in qrtr_ns_remove
A null-ptr-deref bug is reported by Hulk Robot like this:
--
KASAN: null-ptr-deref in range [0x0128-0x012f]
Call Trace:
qrtr_ns_remove+0x22/0x40 [ns]
qrtr_proto_fini+0xa/0x31 [qrtr]
__x64_sys_delete_module+0x337/0x4e0
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x468ded
--
When qrtr_ns_init fails in qrtr_proto_init, qrtr_ns_remove which would
be called later on would raise a null-ptr-deref because qrtr_ns.workqueue
has been destroyed.
Fix it by making qrtr_ns_init have a return value and adding a check in
qrtr_proto_init.
Reported-by: Hulk Robot
Signed-off-by: Qinglang Miao
---
v1->v2: remove redundant braces for single statement blocks.
net/qrtr/ns.c | 7 ---
net/qrtr/qrtr.c | 16 +++-
net/qrtr/qrtr.h | 2 +-
3 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index 56aaf8cb6..8d00dfe81 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -755,7 +755,7 @@ static void qrtr_ns_data_ready(struct sock *sk)
queue_work(qrtr_ns.workqueue, _ns.work);
}
-void qrtr_ns_init(void)
+int qrtr_ns_init(void)
{
struct sockaddr_qrtr sq;
int ret;
@@ -766,7 +766,7 @@ void qrtr_ns_init(void)
ret = sock_create_kern(_net, AF_QIPCRTR, SOCK_DGRAM,
PF_QIPCRTR, _ns.sock);
if (ret < 0)
- return;
+ return ret;
ret = kernel_getsockname(qrtr_ns.sock, (struct sockaddr *));
if (ret < 0) {
@@ -797,12 +797,13 @@ void qrtr_ns_init(void)
if (ret < 0)
goto err_wq;
- return;
+ return 0;
err_wq:
destroy_workqueue(qrtr_ns.workqueue);
err_sock:
sock_release(qrtr_ns.sock);
+ return ret;
}
EXPORT_SYMBOL_GPL(qrtr_ns_init);
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index f4ab3ca6d..b34358282 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -1287,13 +1287,19 @@ static int __init qrtr_proto_init(void)
return rc;
rc = sock_register(_family);
- if (rc) {
- proto_unregister(_proto);
- return rc;
- }
+ if (rc)
+ goto err_proto;
- qrtr_ns_init();
+ rc = qrtr_ns_init();
+ if (rc)
+ goto err_sock;
+ return 0;
+
+err_sock:
+ sock_unregister(qrtr_family.family);
+err_proto:
+ proto_unregister(_proto);
return rc;
}
postcore_initcall(qrtr_proto_init);
diff --git a/net/qrtr/qrtr.h b/net/qrtr/qrtr.h
index dc2b67f17..3f2d28696 100644
--- a/net/qrtr/qrtr.h
+++ b/net/qrtr/qrtr.h
@@ -29,7 +29,7 @@ void qrtr_endpoint_unregister(struct qrtr_endpoint *ep);
int qrtr_endpoint_post(struct qrtr_endpoint *ep, const void *data, size_t len);
-void qrtr_ns_init(void);
+int qrtr_ns_init(void);
void qrtr_ns_remove(void);
--
2.23.0
RE: [PATCH v3 3/3] iommu/vt-d: Fix ineffective devTLB invalidation for subdevices
Hi Baolu,
> From: Lu Baolu
> Sent: Tuesday, December 29, 2020 4:42 PM
>
> Hi Yi,
>
> On 2020/12/29 11:25, Liu Yi L wrote:
> > iommu_flush_dev_iotlb() is called to invalidate caches on device. It only
> > loops the devices which are full-attached to the domain. For sub-devices,
> > this is ineffective. This results in invalid caching entries left on the
> > device. Fix it by adding loop for subdevices as well. Also, the domain->
> > has_iotlb_device needs to be updated when attaching to subdevices.
> >
> > Fixes: 67b8e02b5e761 ("iommu/vt-d: Aux-domain specific domain
> attach/detach")
> > Signed-off-by: Liu Yi L
> > ---
> > drivers/iommu/intel/iommu.c | 53 ++-
> --
> > 1 file changed, 37 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> > index d7720a836268..d48a60b61ba6 100644
> > --- a/drivers/iommu/intel/iommu.c
> > +++ b/drivers/iommu/intel/iommu.c
> > @@ -719,6 +719,8 @@ static int domain_update_device_node(struct
> dmar_domain *domain)
> > return nid;
> > }
> >
> > +static void domain_update_iotlb(struct dmar_domain *domain);
> > +
> > /* Some capabilities may be different across iommus */
> > static void domain_update_iommu_cap(struct dmar_domain *domain)
> > {
> > @@ -744,6 +746,8 @@ static void domain_update_iommu_cap(struct
> dmar_domain *domain)
> > domain->domain.geometry.aperture_end =
> __DOMAIN_MAX_ADDR(domain->gaw - 1);
> > else
> > domain->domain.geometry.aperture_end =
> __DOMAIN_MAX_ADDR(domain->gaw);
> > +
> > + domain_update_iotlb(domain);
> > }
> >
> > struct context_entry *iommu_context_addr(struct intel_iommu *iommu,
> u8 bus,
> > @@ -1464,17 +1468,22 @@ static void domain_update_iotlb(struct
> dmar_domain *domain)
> >
> > assert_spin_locked(_domain_lock);
> >
> > - list_for_each_entry(info, >devices, link) {
> > - struct pci_dev *pdev;
> > -
> > - if (!info->dev || !dev_is_pci(info->dev))
> > - continue;
> > -
> > - pdev = to_pci_dev(info->dev);
> > - if (pdev->ats_enabled) {
> > + list_for_each_entry(info, >devices, link)
> > + if (info && info->ats_enabled) {
> > has_iotlb_device = true;
> > break;
> > }
> > +
> > + if (!has_iotlb_device) {
> > + struct subdev_domain_info *sinfo;
> > +
> > + list_for_each_entry(sinfo, >subdevices,
> link_domain) {
> > + info = get_domain_info(sinfo->pdev);
> > + if (info && info->ats_enabled) {
> > + has_iotlb_device = true;
> > + break;
> > + }
> > + }
> > }
> >
> > domain->has_iotlb_device = has_iotlb_device;
> > @@ -1555,25 +1564,37 @@ static void iommu_disable_dev_iotlb(struct
> device_domain_info *info)
> > #endif
> > }
> >
> > +static void __iommu_flush_dev_iotlb(struct device_domain_info *info,
> > + u64 addr, unsigned int mask)
> > +{
> > + u16 sid, qdep;
> > +
> > + if (!info || !info->ats_enabled)
> > + return;
> > +
> > + sid = info->bus << 8 | info->devfn;
> > + qdep = info->ats_qdep;
> > + qi_flush_dev_iotlb(info->iommu, sid, info->pfsid,
> > + qdep, addr, mask);
> > +}
> > +
> > static void iommu_flush_dev_iotlb(struct dmar_domain *domain,
> > u64 addr, unsigned mask)
> > {
> > - u16 sid, qdep;
> > unsigned long flags;
> > struct device_domain_info *info;
> > + struct subdev_domain_info *sinfo;
> >
> > if (!domain->has_iotlb_device)
> > return;
> >
> > spin_lock_irqsave(_domain_lock, flags);
> > - list_for_each_entry(info, >devices, link) {
> > - if (!info->ats_enabled)
> > - continue;
> > + list_for_each_entry(info, >devices, link)
> > + __iommu_flush_dev_iotlb(info, addr, mask);
> >
> > - sid = info->bus << 8 | info->devfn;
> > - qdep = info->ats_qdep;
> > - qi_flush_dev_iotlb(info->iommu, sid, info->pfsid,
> > - qdep, addr, mask);
> > + list_for_each_entry(sinfo, >subdevices, link_domain) {
> > + __iommu_flush_dev_iotlb(get_domain_info(sinfo->pdev),
> > + addr, mask);
> > }
>
> Nit:
> list_for_each_entry(sinfo, >subdevices, link_domain) {
> info = get_domain_info(sinfo->pdev);
> __iommu_flush_dev_iotlb(info, addr, mask);
> }
you are right. this should be better.
> Others look good to me.
>
> Acked-by: Lu Baolu
>
> Best regards,
> baolu
Regards,
Yi Liu
> > spin_unlock_irqrestore(_domain_lock, flags);
> > }
> >
Re: [PATCH] arm64: add pmem module for kernel update
Hi Zhuling, On Wed, Dec 30, 2020 at 10:18 PM Zhuling wrote: > > Category: feature > Bugzilla: NA > CVE: NA These tags can be dropped. > > Use reserved memory to create a pmem device to store the > processes information that dumped before kernel update. > When you want to use this feature you need to declare by > "pmemmem=pmem_size:pmem_phystart" in cmdline. > (exp: pmemmem=100M:0x2020) > Interesting. I like the feature, but it's not clear to me that a new command line based configuration scheme is needed. There is the existing memmap= parameter that on x86 describes a IORES_DESC_PERSISTENT_MEMORY_LEGACY range. The driver/nvdimm/e820.c driver could be reworked to attach to the same thing on ARM64. Then as far as assigning memory to different kernel usages there is the existing capability in libnvdimm to attach a "personality" to an nvdimm namespace. I imagine you could write a special signature to the namespace that libnvdimm would recognize as a KUP reservation namespace and work generically across any arch.
[PATCH v2] drivers core: Free dma_range_map when driver probe failed
From: Limeng There will be memory leak if driver probe failed. Trace as below: backtrace: [<2415258f>] kmemleak_alloc+0x3c/0x50 [] __kmalloc+0x208/0x530 [<48bc7b3a>] of_dma_get_range+0xe4/0x1b0 [<41e39065>] of_dma_configure_id+0x58/0x27c [<6356866a>] platform_dma_configure+0x2c/0x40 .. [<0afcf9b5>] ret_from_fork+0x10/0x3c This issue is introduced by commit e0d072782c73("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset "). It doesn't free dma_range_map when driver probe failed and cause above memory leak. So, add code to free it in error path. v2: set dev->dma_range_map as NULL after memory free. Fixes: e0d072782c73("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset ") Cc: sta...@vger.kernel.org Signed-off-by: Meng Li --- drivers/base/dd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 148e81969e04..3c94ebc8d4bb 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -612,6 +612,8 @@ static int really_probe(struct device *dev, struct device_driver *drv) else if (drv->remove) drv->remove(dev); probe_failed: + kfree(dev->dma_range_map); + dev->dma_range_map = NULL; if (dev->bus) blocking_notifier_call_chain(>bus->p->bus_notifier, BUS_NOTIFY_DRIVER_NOT_BOUND, dev); -- 2.17.1
Re: [PATCH] tee: optee: replace might_sleep with cond_resched
On Fri, 25 Sept 2020 at 12:29, Jens Wiklander via OP-TEE
wrote:
>
> On Fri, Sep 18, 2020 at 7:45 PM Rouven Czerwinski
> wrote:
> >
> > On Kernels with CONFIG_PREEMPT_NONE might_sleep() is not enough to force
> > rescheduling, replace it with a resched check and cond_resched. Fixes
> > the following stall:
> >
> > [ 572.945146] rcu: INFO: rcu_sched self-detected stall on CPU
> > [ 572.949275] rcu: 0-: (2099 ticks this GP)
> > idle=572/1/0x4002 softirq=7412/7412 fqs=974
> > [ 572.957964] (t=2100 jiffies g=10393 q=21)
> > [ 572.962054] NMI backtrace for cpu 0
> > [ 572.965540] CPU: 0 PID: 165 Comm: xtest Not tainted 5.8.7 #1
> > [ 572.971188] Hardware name: STM32 (Device Tree Support)
> > [ 572.976354] [] (unwind_backtrace) from []
> > (show_stack+0x10/0x14)
> > [ 572.984080] [] (show_stack) from []
> > (dump_stack+0xc4/0xd8)
> > [ 572.991300] [] (dump_stack) from []
> > (nmi_cpu_backtrace+0x90/0xc4)
> > [ 572.999130] [] (nmi_cpu_backtrace) from []
> > (nmi_trigger_cpumask_backtrace+0xec/0x130)
> > [ 573.008706] [] (nmi_trigger_cpumask_backtrace) from
> > [] (rcu_dump_cpu_stacks+0xe8/0x110)
> > [ 573.018453] [] (rcu_dump_cpu_stacks) from []
> > (rcu_sched_clock_irq+0x7fc/0xa88)
> > [ 573.027416] [] (rcu_sched_clock_irq) from []
> > (update_process_times+0x30/0x8c)
> > [ 573.036291] [] (update_process_times) from []
> > (tick_sched_timer+0x4c/0xa8)
> > [ 573.044905] [] (tick_sched_timer) from []
> > (__hrtimer_run_queues+0x174/0x358)
> > [ 573.053696] [] (__hrtimer_run_queues) from []
> > (hrtimer_interrupt+0x118/0x2bc)
> > [ 573.062573] [] (hrtimer_interrupt) from []
> > (arch_timer_handler_virt+0x28/0x30)
> > [ 573.071536] [] (arch_timer_handler_virt) from []
> > (handle_percpu_devid_irq+0x8c/0x240)
> > [ 573.081109] [] (handle_percpu_devid_irq) from []
> > (generic_handle_irq+0x34/0x44)
> > [ 573.090156] [] (generic_handle_irq) from []
> > (__handle_domain_irq+0x5c/0xb0)
> > [ 573.098857] [] (__handle_domain_irq) from []
> > (gic_handle_irq+0x4c/0x90)
> > [ 573.107209] [] (gic_handle_irq) from []
> > (__irq_svc+0x6c/0x90)
> > [ 573.114682] Exception stack(0xd90dfcf8 to 0xd90dfd40)
> > [ 573.119732] fce0:
> > 0004
> > [ 573.127917] fd00:
> > d93493cc
> > [ 573.136098] fd20: d2bc39c0 be926998 d90dfd58 d90dfd48 c09f3384
> > c01151f0 400d0013
> > [ 573.144281] [] (__irq_svc) from []
> > (__arm_smccc_smc+0x10/0x20)
> > [ 573.151854] [] (__arm_smccc_smc) from []
> > (optee_smccc_smc+0x3c/0x44)
> > [ 573.159948] [] (optee_smccc_smc) from []
> > (optee_do_call_with_arg+0xb8/0x154)
> > [ 573.168735] [] (optee_do_call_with_arg) from []
> > (optee_invoke_func+0x110/0x190)
> > [ 573.177786] [] (optee_invoke_func) from []
> > (tee_ioctl+0x10b8/0x11c0)
> > [ 573.185879] [] (tee_ioctl) from []
> > (ksys_ioctl+0xe0/0xa4c)
> > [ 573.193101] [] (ksys_ioctl) from []
> > (ret_fast_syscall+0x0/0x54)
> > [ 573.200750] Exception stack(0xd90dffa8 to 0xd90dfff0)
> > [ 573.205803] ffa0: be926bf4 be926a78 0003
> > 8010a403 be926908 004e3cf8
> > [ 573.213987] ffc0: be926bf4 be926a78 0036 be926908
> > be926918 be9269b0 bffdf0f8
> > [ 573.222162] ffe0: b6d76fb0 be9268fc b6d66621 b6c7e0d8
> >
> > seen on STM32 DK2.
> >
> > Signed-off-by: Rouven Czerwinski
> > ---
> > drivers/tee/optee/call.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
> > index 20b6fd7383c5..83b73b1d52f0 100644
> > --- a/drivers/tee/optee/call.c
> > +++ b/drivers/tee/optee/call.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -148,7 +149,8 @@ u32 optee_do_call_with_arg(struct tee_context *ctx,
> > phys_addr_t parg)
> > */
> > optee_cq_wait_for_completion(>call_queue,
> > );
> > } else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) {
> > - might_sleep();
> > + if(need_resched())
> > + cond_resched();
>
> This looks OK to me. But I'd prefer if someone else could confirm this too.
>
Tested-by: Sumit Garg
-Sumit
> Thanks,
> Jens
>
> > param.a0 = res.a0;
> > param.a1 = res.a1;
> > param.a2 = res.a2;
> > --
> > 2.28.0
> >
[PATCH v2 2/2] arm64: dts: mt8192: Add node for the Mali GPU
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https://lore.kernel.org/patchwork/patch/1356037/
[4]https://patchwork.kernel.org/project/linux-mediatek/list/?series=405777
[5]https://lore.kernel.org/patchwork/patch/1356175/
[6]https://patchwork.kernel.org/project/linux-mediatek/patch/1605700894-32699-6-git-send-email-hsin-hsiung.w...@mediatek.com/
[7]https://patchwork.kernel.org/project/linux-mediatek/patch/1608104827-7937-10-git-send-email-hsin-hsiung.w...@mediatek.com/
---
---
arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 7 +
arch/arm64/boot/dts/mediatek/mt8192.dtsi| 176
2 files changed, 183 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 6c1e2b3e8a60..48c0e240dd92 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -5,6 +5,7 @@
*/
/dts-v1/;
#include "mt8192.dtsi"
+#include "mt6359.dtsi"
/ {
model = "MediaTek MT8192 evaluation board";
@@ -70,6 +71,12 @@
};
};
+ {
+ supply-names = "mali","sram";
+ mali-supply = <_7_vbuck1>;
+ sram-supply = <_vsram_others_ldo_reg>;
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index d6a4ad242a33..de166ea750af 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -822,6 +822,182 @@
#clock-cells = <1>;
};
+ gpu: mali@1300 {
+ compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
+ reg = <0 0x1300 0 0x4000>;
+ interrupts =
+ ,
+ ,
+ ,
+ ,
+ ;
+ interrupt-names =
+ "GPU",
+ "MMU",
+ "JOB",
+ "EVENT",
+ "PWR";
+
+ clocks =
+ < CLK_APMIXED_MFGPLL>,
+ < CLK_TOP_MFG_PLL_SEL>,
+ < CLK_TOP_MFG_REF_SEL>,
+ < CLK_MFG_BG3D>;
+ clock-names =
+ "clk_main_parent",
+ "clk_mux",
+ "clk_sub_parent",
+ "subsys_mfg_cg";
+
+ power-domains =
+ < MT8192_POWER_DOMAIN_MFG2>,
+ < MT8192_POWER_DOMAIN_MFG3>,
+ < MT8192_POWER_DOMAIN_MFG4>,
+ < MT8192_POWER_DOMAIN_MFG5>,
+ < MT8192_POWER_DOMAIN_MFG6>;
+ power-domain-names = "core0",
+"core1",
+"core2",
+"core3",
+"core4";
+
+ operating-points-v2 = <_opp_table>;
+ #cooling-cells = <2>;
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-35800 {
+ opp-hz = /bits/ 64 <35800>;
+ opp-hz-real = /bits/ 64 <35800>,
+ /bits/ 64 <35800>;
+ opp-microvolt = <606250>,
+ <75>;
+ };
+
+ opp-39900 {
+ opp-hz = /bits/ 64 <39900>;
+ opp-hz-real = /bits/ 64 <39900>,
+ /bits/ 64 <39900>;
+ opp-microvolt = <618750>,
+ <75>;
+ };
+
+ opp-44000 {
+ opp-hz = /bits/ 64 <44000>;
+ opp-hz-real = /bits/ 64 <44000>,
+ /bits/ 64 <44000>;
+ opp-microvolt = <631250>,
+ <75>;
+ };
+
+ opp-48200 {
+
Re: [PATCH 31/31] PM / devfreq: convert to devm_pm_opp_register_notifier and remove unused API
On Sun, Jan 3, 2021 at 12:59 PM Yangtao Li wrote:
>
> Use devm_pm_opp_* API to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/devfreq.c | 66 +--
> include/linux/devfreq.h | 23 --
> 2 files changed, 1 insertion(+), 88 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 6aa10de792b3..f593f30529ec 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -2004,40 +2004,6 @@ struct dev_pm_opp *devfreq_recommended_opp(struct
> device *dev,
> }
> EXPORT_SYMBOL(devfreq_recommended_opp);
>
> -/**
> - * devfreq_register_opp_notifier() - Helper function to get devfreq notified
> - * for any changes in the OPP availability
> - * changes
> - * @dev: The devfreq user device. (parent of devfreq)
> - * @devfreq: The devfreq object.
> - */
> -int devfreq_register_opp_notifier(struct device *dev, struct devfreq
> *devfreq)
> -{
> - return dev_pm_opp_register_notifier(dev, >nb);
> -}
> -EXPORT_SYMBOL(devfreq_register_opp_notifier);
> -
> -/**
> - * devfreq_unregister_opp_notifier() - Helper function to stop getting
> devfreq
> - *notified for any changes in the OPP
> - *availability changes anymore.
> - * @dev: The devfreq user device. (parent of devfreq)
> - * @devfreq: The devfreq object.
> - *
> - * At exit() callback of devfreq_dev_profile, this must be included if
> - * devfreq_recommended_opp is used.
> - */
> -int devfreq_unregister_opp_notifier(struct device *dev, struct devfreq
> *devfreq)
> -{
> - return dev_pm_opp_unregister_notifier(dev, >nb);
> -}
> -EXPORT_SYMBOL(devfreq_unregister_opp_notifier);
> -
> -static void devm_devfreq_opp_release(struct device *dev, void *res)
> -{
> - devfreq_unregister_opp_notifier(dev, *(struct devfreq **)res);
> -}
> -
> /**
> * devm_devfreq_register_opp_notifier() - Resource-managed
> * devfreq_register_opp_notifier()
> @@ -2047,40 +2013,10 @@ static void devm_devfreq_opp_release(struct device
> *dev, void *res)
> int devm_devfreq_register_opp_notifier(struct device *dev,
>struct devfreq *devfreq)
> {
> - struct devfreq **ptr;
> - int ret;
> -
> - ptr = devres_alloc(devm_devfreq_opp_release, sizeof(*ptr),
> GFP_KERNEL);
> - if (!ptr)
> - return -ENOMEM;
> -
> - ret = devfreq_register_opp_notifier(dev, devfreq);
> - if (ret) {
> - devres_free(ptr);
> - return ret;
> - }
> -
> - *ptr = devfreq;
> - devres_add(dev, ptr);
> -
> - return 0;
> + return devm_pm_opp_register_notifier(dev, >nb);
> }
> EXPORT_SYMBOL(devm_devfreq_register_opp_notifier);
>
> -/**
> - * devm_devfreq_unregister_opp_notifier() - Resource-managed
> - * devfreq_unregister_opp_notifier()
> - * @dev: The devfreq user device. (parent of devfreq)
> - * @devfreq: The devfreq object.
> - */
> -void devm_devfreq_unregister_opp_notifier(struct device *dev,
> -struct devfreq *devfreq)
> -{
> - WARN_ON(devres_release(dev, devm_devfreq_opp_release,
> - devm_devfreq_dev_match, devfreq));
> -}
> -EXPORT_SYMBOL(devm_devfreq_unregister_opp_notifier);
Need to support devm_devfreq_unregister_opp_notifier()
because sometimes, the user wants to release the resource by himself.
(snip)
Best Regards,
Chanwoo Choi
[PATCH v2 1/2] dt-bindings: Add DT schema for Arm Mali Valhall GPU
Add devicetree schema for Arm Mali Valhall GPU
Define a compatible string for the Mali Valhall GPU
for Mediatek's SoC platform.
Signed-off-by: Nick Fan
---
.../bindings/gpu/arm,mali-valhall.yaml| 252 ++
1 file changed, 252 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
new file mode 100644
index ..436294c032ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
@@ -0,0 +1,252 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/arm,mali-valhall.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Mali Valhall GPU
+
+maintainers:
+ - Rob Herring
+
+properties:
+ $nodename:
+pattern: '^gpu@[a-f0-9]+$'
+
+ compatible:
+items:
+ - enum:
+ - mediatek,mt8192-mali
+ - const: arm,mali-valhall
+
+ reg:
+maxItems: 1
+
+ interrupts:
+items:
+ - description: GPU interrupt
+ - description: MMU interrupt
+ - description: Job interrupt
+
+ interrupt-names:
+items:
+ - const: gpu
+ - const: mmu
+ - const: job
+
+ clocks:
+minItems: 1
+
+ power-domains:
+minItems: 1
+maxItems: 5
+
+ mali-supply: true
+ sram-supply: true
+
+ operating-points-v2: true
+
+ "#cooling-cells":
+const: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: mediatek,mt8192-mali
+then:
+ properties:
+sram-supply: true
+power-domains:
+ description:
+List of phandle and PM domain specifier as documented in
+Documentation/devicetree/bindings/power/power_domain.txt
+ minItems: 5
+ maxItems: 5
+power-domain-names:
+ items:
+- const: core0
+- const: core1
+- const: core2
+- const: core3
+- const: core4
+
+ required:
+- sram-supply
+- power-domains
+
+examples:
+ - |
+#include
+#include
+
+gpu@1300 {
+ compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
+ reg = <0x1300 0x4000>;
+ interrupts =
+ ,
+ ,
+ ;
+ interrupt-names =
+ "gpu",
+ "mmu",
+ "job";
+
+ clocks = < 0>;
+
+ power-domains =
+ < 4>,
+ < 5>,
+ < 6>,
+ < 7>,
+ < 8>;
+
+ operating-points-v2 = <_opp_table>;
+ mali-supply = <_7_vbuck1>;
+ sram-supply = <_vsram_others_ldo_reg>;
+};
+
+gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-35800 {
+ opp-hz = /bits/ 64 <35800>;
+ opp-hz-real = /bits/ 64 <35800>,
+/bits/ 64 <35800>;
+ opp-microvolt = <606250>,
+ <75>;
+ };
+
+ opp-39900 {
+ opp-hz = /bits/ 64 <39900>;
+ opp-hz-real = /bits/ 64 <39900>,
+/bits/ 64 <39900>;
+ opp-microvolt = <618750>,
+ <75>;
+ };
+
+ opp-44000 {
+ opp-hz = /bits/ 64 <44000>;
+ opp-hz-real = /bits/ 64 <44000>,
+/bits/ 64 <44000>;
+ opp-microvolt = <631250>,
+ <75>;
+ };
+
+ opp-48200 {
+ opp-hz = /bits/ 64 <48200>;
+ opp-hz-real = /bits/ 64 <48200>,
+/bits/ 64 <48200>;
+ opp-microvolt = <643750>,
+ <75>;
+ };
+
+ opp-52300 {
+ opp-hz = /bits/ 64 <52300>;
+ opp-hz-real = /bits/ 64 <52300>,
+/bits/ 64 <52300>;
+ opp-microvolt = <656250>,
+ <75>;
+ };
+
+ opp-56400 {
+ opp-hz = /bits/ 64 <56400>;
+ opp-hz-real = /bits/ 64 <56400>,
+/bits/ 64 <56400>;
+ opp-microvolt = <668750>,
+ <75>;
+ };
+
+ opp-60500 {
+ opp-hz = /bits/ 64 <60500>;
+ opp-hz-real = /bits/ 64 <60500>,
+/bits/ 64 <60500>;
+ opp-microvolt = <681250>,
+
Re: uninitialized pmem struct pages
On Mon, Jan 4, 2021 at 7:59 AM Michal Hocko wrote: > > On Mon 04-01-21 16:43:49, David Hildenbrand wrote: > > On 04.01.21 16:33, Michal Hocko wrote: > > > On Mon 04-01-21 16:15:23, David Hildenbrand wrote: > > >> On 04.01.21 16:10, Michal Hocko wrote: > > > [...] > > >> Do the physical addresses you see fall into the same section as boot > > >> memory? Or what's around these addresses? > > > > > > Yes I am getting a garbage for the first struct page belonging to the > > > pmem section [1] > > > [0.020161] ACPI: SRAT: Node 0 PXM 0 [mem 0x1-0x603fff] > > > [0.020163] ACPI: SRAT: Node 4 PXM 4 [mem 0x606000-0x11d5fff] > > > non-volatile > > > > > > The pfn without the initialized struct page is 0x606. This is a > > > first pfn in a section. > > > > Okay, so we're not dealing with the "early section" mess I described, > > different story. > > > > Due to [1], is_mem_section_removable() called > > pfn_to_page(PHYS_PFN(0x606)). page_zone(page) made it crash, as not > > initialized. > > Exactly! > > > Let's assume this is indeed a reserved pfn in the altmap. What's the > > actual address of the memmap? > > Not sure what exactly you are asking for but crash says > crash> kmem -p 606 > PAGE PHYSICAL MAPPING INDEX CNT FLAGS > f8c600181800 60600 0 fc000 > > > I do wonder what hosts pfn_to_page(PHYS_PFN(0x606)) - is it actually > > part of the actual altmap (i.e. > 0x606) or maybe even self-hosted? > > I am not really familiar with the pmem so I would need more assistance > here. I've tried this (shot into the dark): > crash> struct page.pgmap f8c600181800 > pgmap = 0xf8c600181808 Does /proc/iomem show an active namespace in the range? You should be able to skip ahead to the first pfn in that namespace to find the first dev_pagemap. I would have expected pfn_to_online_page() to have saved you here. This address range is section aligned.
Re: [PATCH v9 8/8] selinux: include a consumer of the new IMA critical data hook
On 1/4/21 6:13 PM, Paul Moore wrote:
On Mon, Jan 4, 2021 at 6:30 PM Lakshmi Ramasubramanian
wrote:
On 12/23/20 1:10 PM, Paul Moore wrote:
Hi Paul,
Hello.
diff --git a/security/selinux/measure.c b/security/selinux/measure.c
new file mode 100644
index ..b7e24358e11d
--- /dev/null
+++ b/security/selinux/measure.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Measure SELinux state using IMA subsystem.
+ */
+#include
+#include
+#include
+#include "security.h"
+
+/*
+ * This function creates a unique name by appending the timestamp to
+ * the given string. This string is passed as "event_name" to the IMA
+ * hook to measure the given SELinux data.
+ *
+ * The data provided by SELinux to the IMA subsystem for measuring may have
+ * already been measured (for instance the same state existed earlier).
+ * But for SELinux the current data represents a state change and hence
+ * needs to be measured again. To enable this, pass a unique "event_name"
+ * to the IMA hook so that IMA subsystem will always measure the given data.
+ *
+ * For example,
+ * At time T0 SELinux data to be measured is "foo". IMA measures it.
+ * At time T1 the data is changed to "bar". IMA measures it.
+ * At time T2 the data is changed to "foo" again. IMA will not measure it
+ * (since it was already measured) unless the event_name, for instance,
+ * is different in this call.
+ */
+static char *selinux_event_name(const char *name_prefix)
+{
+ struct timespec64 cur_time;
+
+ ktime_get_real_ts64(_time);
+ return kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
+cur_time.tv_sec, cur_time.tv_nsec);
+}
Why is this a separate function? It's three lines long and only
called from selinux_measure_state(). Do you ever see the SELinux/IMA
code in this file expanding to the point where this function is nice
from a reuse standpoint?
Earlier I had two measurements - one for SELinux configuration/state and
another for SELinux policy. selinux_event_name() was used to generate
event name for each of them.
In this patch set I have included only one measurement - for SELinux
policy. I plan to add "SELinux configuration/state" measurement in a
separate patch - I can reuse selinux_event_name() in that patch.
I'm curious about this second measurement. My apologies if you posted
it previously, this patchset has gone through several iterations and
simply can't recall all the different versions without digging through
the list archives.
The 2nd measurement is for SELinux state data such as "enforcing",
"checkreqprot", policycap[__POLICYDB_CAPABILITY_MAX], etc.
Is there a reason why the second measurement isn't included in this
patch? Or this patchset if it is too big to be a single patch?
For illustrating the use of the new IMA hook, that my colleague Tushar
has added for measuring kernel critical data, we have included only one
SELinux measurement in this patch set - the measurement of SELinux
policy. This also helped in keeping this patch smaller.
When this patch set is merged, I'll post a separate patch to add
measurement of SELinux state data I have mentioned above.
Also, I think the comment in the function header for
selinux_event_name() is useful.
I prefer to have a separate function, if that's fine by you.
Given just this patch I would prefer if you folded
selinux_event_name() into selinux_measure_state(). However, I agree
with you that the comments in the selinux_event_name() header block is
useful, I would suggest moving those into the body of
selinux_measure_state() directly above the calls to
ktime_get_real_ts64() and kasprintf().
Sure - I will make that change.
Also, I assume you are not concerned about someone circumventing the
IMA measurements by manipulating the time? In most systems I would
expect the time to be a protected entity, but with many systems
getting their time from remote systems I thought it was worth
mentioning.
I am using time function to generate a unique name for the IMA
measurement event, such as, "selinux-policy-hash-1609790281:860232824".
This is to ensure that state changes in SELinux data are always measured.
If you think time manipulation can be an issue, please let me know a
better way to generate unique event names.
Yes, I understand that you are using the time value as a way of
ensuring you always have a different event name and hence a new
measurement. However, I was wondering if you would be okay if the
time was adjusted such that an event name was duplicated and a
measurement missed? Is that a problem for you? It seems like it
might be an issue, but you and Mimi know IMA better than I do.
If the system time was adjusted such that the event name is duplicated,
we could miss measurements - this is not okay.
For example:
#1 Say, at time T1 SELinux state being measured is "foo" - IMA will
measure it.
#2 at time T2, the state changes to "bar" - IMA will measure it
#3 at time
INVESTMENT BITCOIN FARM
GOOD NEWS TO YOU ALL !!! WE ARE HERE TO INTRODUCE BINARY TRADING TO YOU, A PLATFORM WHERE YOU INVEST A LITTLE AMOUNT OF MONEY AND EARN A FORTUNE (7 TIMES RETURN) IN LESS THAN 48 HOURS TO ALL YOU TRADERS THAT PRIORITIZE LOSING, WE CAN MAKE A FORTUNE AND HELP YOU GROW YOUR INVESTMENT. WITH OUR PREMIUM SIGNALS UP TO 95% WINNING ACCURACY PROFIT RETURN IS GUARANTEED. SETUP INVESTMENT TODAY LET OUR TEAM OF PROFESSIONALS TRADE FOR YOU TO EARN 700% PROFIT RETURN WITHIN 2 DAYS. Invest $ 500 earn $ 3,000 IN 48 HOURS Invest $ 1000 earn $ 6,000 IN 48 HOURS Invest $ 2000 earn $ 12,000 IN 48 HOURS Invest $ 3000 earn $ 18,000 IN 48 HOURS Invest $ 4000 earn $ 24,000 IN 48 HOURS Invest $ 5000 earn $ 30,000 IN 48 HOURS for more information email us now and with our team of professionals trade for you EMAIL: ulsterc...@gmail.com WHATSAPP : +1 647 477 6855 Invest with a professional trader like me and let me help you to grow up your capital just in 2 days and get your 7 times return of your invested funds your money is safe with me okay and you are 100% guaranteed invest today and start making profits for yourself. Thank you. Jonas Kim
[PATCH] [v2] iommu/intel: Fix memleak in intel_irq_remapping_alloc
When irq_domain_get_irq_data() or irqd_cfg() fails
at i == 0, data allocated by kzalloc() has not been
freed before returning, which leads to memleak.
Fixes: b106ee63abccb ("irq_remapping/vt-d: Enhance Intel IR driver to support
hierarchical irqdomains")
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Add a check against i instead of setting data to NULL.
---
drivers/iommu/intel/irq_remapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/intel/irq_remapping.c
b/drivers/iommu/intel/irq_remapping.c
index aeffda92b10b..685200a5cff0 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -1353,6 +1353,8 @@ static int intel_irq_remapping_alloc(struct irq_domain
*domain,
irq_data = irq_domain_get_irq_data(domain, virq + i);
irq_cfg = irqd_cfg(irq_data);
if (!irq_data || !irq_cfg) {
+ if (!i)
+ kfree(data);
ret = -EINVAL;
goto out_free_data;
}
--
2.17.1
Re: uninitialized pmem struct pages
On Mon, Jan 4, 2021 at 2:45 AM David Hildenbrand wrote:
>
> On 04.01.21 11:03, Michal Hocko wrote:
> > Hi,
> > back in March [1] you have recommended 53cdc1cb29e8
> > ("drivers/base/memory.c: indicate all memory blocks as removable") to be
> > backported to stable trees and that has led to a more general discussion
> > about the current state of pfn walkers wrt. uninitialized pmem struct
> > pages. We haven't concluded any specific solution for that except for a
> > general sentiment that pfn_to_online_page should be able to catch those.
> > I might have missed any follow ups on that but I do not think we have
> > landed on any actual solution in the end. Have I just missed any followups?
>
> Thanks for raising this issue. It's still on my list of "broken and
> non-trivial to fix" things.
>
> So, as far as I recall, we still have the following two issues remaining:
>
> 1. pfn_to_online_page() false positives
>
> The semantics of pfn_to_online_page() were broken with sub-section
> hot-add in corner cases.
The motivation for that backport was for pre-subsection kernels. When
onlining pmem that collides with the same section as System-RAM we may
have a situation like:
|-- SECTION -- |
|-- System RAM --PMEM -- |
|-- pfn_valid() -- PMEM metadata-- |
So problem 0. is just System RAM + PMEM collisions independent of
sub-section support.
>
> If we have ZONE_DEVICE hot-added memory that overlaps in a section with
> boot memory, this memory section will contain parts ZONE_DEVICE memory
> and parts !ZONE_DEVICE memory. This can happen in sub-section
> granularity (2MB IIRC). pfn_to_online_page() will succeed on ZONE_DEVICE
> memory parts as the whole section is marked as online. Bad.
>
> One instance where this is still an issue is
> mm/memory-failure.c:memory_failure() and
> mm/memory-failure.c:soft_offline_page(). I thought for a while about
> "fixing" these, but to me it felt like fixing pfn_to_online_page() is
> actually the right approach.
This is complicated by MEMORY_DEVICE_PRIVATE that I believe wants to
say "yes" to pfn_to_online_page().
>
> But worse, before ZONE_DEVICE hot-add
> 1. The whole section memmap does already exist (early sections always
> have a full memmap for the whole section)
> 2. The whole section memmap is initialized (although eventually with
> dummy node/zone 0/0 for memory holes until that part is fixed) and might
> be accessed by pfn walkers.
>
> So when hotadding ZONE_DEVICE we are modifying already existing and
> visible memmaps. Bad.
Where does the rewrite of a dummy page entry matter in practice? It
would certainly be exceedingly Bad if in-use 'struct page' instances
we're rewritten. You're only alleging the former, correct?
>
>
> 2. Deferred init of ZONE_DEVICE ranges
>
> memmap_init_zone_device() runs after the ZONE_DEVICE zone was resized
> and outside the memhp lock. I did not follow if the use of
> get_dev_pagemap() actually makes sure that memmap_init_zone_device() in
> pagemap_range() actually completed. I don't think it does.
>
> >
> > Is anybody working on that?
> >
>
> I believe Dan mentioned somewhere that he wants to see a real instance
> of this producing a BUG before actually moving forward with a fix. I
> might be wrong.
I think I'm missing an argument for the user-visible effects of the
"Bad." statements above. I think soft_offline_page() is a candidate
for a local fix because mm/memory-failure.c already has a significant
amount of page-type specific knowledge. So teaching it "yes" for
MEMORY_DEVICE_PRIVATE-ZONE_DEVICE and "no" for other ZONE_DEVICE seems
ok to me.
>
>
> We might tackle 1. by:
>
> a) [worked-around] doing get_dev_pagemap() before pfn_to_online_page() -
> just plain ugly.
>
> b) [worked-around] using a sub-section online-map and extending
> pfn_to_online_page(). IMHO ugly to fix this corner case.
>
> c) [worked-around] extending pfn_to_online_page() by zone checks. IMHO racy.
>
> d) fixed by not allowing ZONE_DEVICE and !ZONE_DEVICE within a single
> section. In the worst case, don't add partially present sections that
> have big holes in the beginning/end. Like, if there is a 128MB section
> with 126MB of memory followed by a 2MB hole, don't add that memory to
> Linux with CONFIG_ZONE_DEVICE. Might turn some memory unusable, but
> well, it would be the price to pay for simplicity. Being able to hotadd
> PMEM is more important than using each and every last MB of memory.
The collisions that are out there in the wild are 64MB System RAM
followed by 64MB of PMEM. If you're suggesting reducing System RAM
that collides with PMEM that's a consideration. It can't go the other
way because there are deployed configurations that have persistent
data there. Reducing System RAM runs into the problem of how early
does the kernel know that it's bordering ZONE_DEVICE. It's not just
PMEM, it's also EFI_MEMORY_SP (Linux Soft Reserved) memory.
> e) decrease the section size and drop
Re: [PATCH] dt-bindings: display: Use OF graph schema
Hi Rob, Thank you for the patch. On Mon, Jan 04, 2021 at 11:07:23AM -0700, Rob Herring wrote: > Now that we have a graph schema, rework the display related schemas to use > it. Mostly this is adding a reference to graph.yaml and dropping duplicate > parts from schemas. > > In panel-common.yaml, 'ports' is dropped. Any binding using 'ports' > should be one with more than 1 port node, and the binding must define > what each port is. > > Note that ti,sn65dsi86.yaml, ti,tfp410,yaml and toshiba,tc358768.yaml will > need further updates to use video-interfaces.yaml once that lands. > > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Laurent Pinchart > Cc: Maxime Ripard > Cc: Maarten Lankhorst > Cc: Thomas Zimmermann > Signed-off-by: Rob Herring Reviewed-by: Laurent Pinchart > --- > v3: > - Rework based on graph.yaml changes. 'port' nodes now have a $ref and >endpoint nodes do too if they define additional properties. > - Convert ste,mcde.yaml > > v2: > - Drop 'type: object' where we have a $ref > - Drop any common properties like 'reg', '#address-cells', "#size-cells', >'remote-endpoint' > - Keep description in ti,k2g-dss.yaml > --- > .../allwinner,sun4i-a10-display-backend.yaml | 23 +--- > .../allwinner,sun4i-a10-display-frontend.yaml | 19 +-- > .../display/allwinner,sun4i-a10-hdmi.yaml | 19 +-- > .../display/allwinner,sun4i-a10-tcon.yaml | 25 +--- > .../allwinner,sun4i-a10-tv-encoder.yaml | 6 +- > .../display/allwinner,sun6i-a31-drc.yaml | 19 +-- > .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 6 +- > .../allwinner,sun8i-a83t-de2-mixer.yaml | 19 +-- > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 19 +-- > .../display/allwinner,sun8i-r40-tcon-top.yaml | 110 ++ > .../display/allwinner,sun9i-a80-deu.yaml | 19 +-- > .../display/amlogic,meson-dw-hdmi.yaml| 4 +- > .../bindings/display/amlogic,meson-vpu.yaml | 4 +- > .../bindings/display/brcm,bcm2835-dpi.yaml| 7 +- > .../display/bridge/analogix,anx7625.yaml | 6 +- > .../display/bridge/analogix,anx7814.yaml | 19 +-- > .../bindings/display/bridge/anx6345.yaml | 18 +-- > .../display/bridge/cdns,mhdp8546.yaml | 22 +--- > .../display/bridge/chrontel,ch7033.yaml | 6 +- > .../display/bridge/intel,keembay-dsi.yaml | 14 +-- > .../bindings/display/bridge/ite,it6505.yaml | 2 +- > .../display/bridge/lontium,lt9611.yaml| 70 ++- > .../bindings/display/bridge/lvds-codec.yaml | 18 +-- > .../bindings/display/bridge/nwl-dsi.yaml | 41 ++- > .../bindings/display/bridge/ps8640.yaml | 24 +--- > .../bindings/display/bridge/renesas,lvds.yaml | 18 +-- > .../display/bridge/simple-bridge.yaml | 18 +-- > .../display/bridge/snps,dw-mipi-dsi.yaml | 7 +- > .../display/bridge/thine,thc63lvd1024.yaml| 21 +--- > .../bindings/display/bridge/ti,sn65dsi86.yaml | 45 +-- > .../bindings/display/bridge/ti,tfp410.yaml| 24 +--- > .../display/bridge/toshiba,tc358762.yaml | 52 + > .../display/bridge/toshiba,tc358768.yaml | 48 +--- > .../display/bridge/toshiba,tc358775.yaml | 19 +-- > .../connector/analog-tv-connector.yaml| 1 + > .../display/connector/dvi-connector.yaml | 1 + > .../display/connector/hdmi-connector.yaml | 1 + > .../display/connector/vga-connector.yaml | 1 + > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 2 +- > .../bindings/display/ingenic,lcd.yaml | 10 +- > .../display/intel,keembay-display.yaml| 2 +- > .../display/panel/advantech,idk-2121wr.yaml | 21 ++-- > .../bindings/display/panel/panel-common.yaml | 11 +- > .../rockchip/rockchip,rk3066-hdmi.yaml| 16 +-- > .../display/rockchip/rockchip-vop.yaml| 5 +- > .../bindings/display/st,stm32-dsi.yaml| 12 +- > .../bindings/display/st,stm32-ltdc.yaml | 8 +- > .../devicetree/bindings/display/ste,mcde.yaml | 5 +- > .../bindings/display/ti/ti,am65x-dss.yaml | 19 +-- > .../bindings/display/ti/ti,j721e-dss.yaml | 23 +--- > .../bindings/display/ti/ti,k2g-dss.yaml | 3 +- > 51 files changed, 185 insertions(+), 747 deletions(-) -- Regards, Laurent Pinchart
Re: [PATCH v3] arch/arc: add copy_user_page() to to fix build error on ARC
On 1/4/21 7:44 PM, Randy Dunlap wrote: > fs/dax.c uses copy_user_page() but ARC does not provide that interface, > resulting in a build error. > > Provide copy_user_page() in . > > ../fs/dax.c: In function 'copy_cow_page_dax': > ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; > did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] > > Reported-by: kernel test robot > Signed-off-by: Randy Dunlap > Cc: Vineet Gupta > Cc: linux-snps-...@lists.infradead.org > Cc: Dan Williams > #Acked-by: Vineet Gupta # v1 > Cc: Andrew Morton > Cc: Matthew Wilcox > Cc: Jan Kara > Cc: linux-fsde...@vger.kernel.org > Cc: linux-nvd...@lists.01.org > #Reviewed-by: Ira Weiny # v2 Added to arc #for-curr. Thx, -Vineet > --- > v2: rebase, add more Cc: > v3: add copy_user_page() to arch/arc/include/asm/page.h > > arch/arc/include/asm/page.h |1 + > > --- lnx-511-rc1.orig/arch/arc/include/asm/page.h > +++ lnx-511-rc1/arch/arc/include/asm/page.h > @@ -10,6 +10,7 @@ > #ifndef __ASSEMBLY__ > > #define clear_page(paddr) memset((paddr), 0, PAGE_SIZE) > +#define copy_user_page(to, from, vaddr, pg) copy_page(to, from) > #define copy_page(to, from) memcpy((to), (from), PAGE_SIZE) > > struct vm_area_struct; >
[GIT PULL] ARC updates for 5.11-rc3
Hi Linus, Happy New Year. Sorry for the delayed merge window material - holidays got in the way. Things are quieter on upstreaming front as we are mostly focusing on ARCv3/ARC64 port. Please pull. Thx, -Vineet ---> The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da: Linux 5.10-rc6 (2020-11-29 15:50:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-5.11-rc3 for you to fetch changes up to 3a71e423133a4b1166ffafcb4a7cfa87ddecb910: ARC: build: use $(READELF) instead of hard-coded readelf (2020-12-01 17:24:05 -0800) ARC updates for 5.11-rc3 - build system updates from Masahiro Yamada Masahiro Yamada (6): ARC: build: remove non-existing bootpImage from KBUILD_IMAGE ARC: build: add uImage.lzma to the top-level target ARC: build: add boot_targets to PHONY ARC: build: move symlink creation to arch/arc/Makefile to avoid race ARC: build: remove unneeded extra-y ARC: build: use $(READELF) instead of hard-coded readelf arch/arc/Makefile | 20 +--- arch/arc/boot/Makefile | 18 -- 2 files changed, 17 insertions(+), 21 deletions(-)
Re: [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas
Hi Rob, Thank you for the patch. On Mon, Jan 04, 2021 at 09:58:08AM -0700, Rob Herring wrote: > Now that we have graph and video-interfaces schemas, rework the media > related schemas to use them. > > Cc: Maxime Ripard > Cc: Mauro Carvalho Chehab > Cc: Jacopo Mondi > Cc: Laurent Pinchart > Cc: linux-me...@vger.kernel.org > Signed-off-by: Rob Herring Reviewed-by: Laurent Pinchart I'm very happy to see this landing in v5.12 :-) > --- > v4: > - Fix incorrect ref 'video-interface-device.yaml' in ovti,ov02a10.yaml > - Explicitly list common properties used in mipi-ccs and ovti,ov02a10 > - Add back description of link-frequencies driver limitations in ov8856 > > v3: > - Add mipi-ccs.yaml, ovti,ov02a10.yaml > > v2: > - Update based on graph schema changes and addition of video-interfaces >schemas > --- > .../media/allwinner,sun4i-a10-csi.yaml| 11 +- > .../media/allwinner,sun6i-a31-csi.yaml| 12 +- > .../bindings/media/i2c/adv7180.yaml | 36 ++ > .../bindings/media/i2c/adv7604.yaml | 37 ++ > .../bindings/media/i2c/aptina,mt9v111.yaml| 4 +- > .../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 30 + > .../devicetree/bindings/media/i2c/imx219.yaml | 21 ++-- > .../bindings/media/i2c/maxim,max9286.yaml | 101 > .../bindings/media/i2c/mipi-ccs.yaml | 17 ++- > .../devicetree/bindings/media/i2c/ov5647.yaml | 20 +--- > .../devicetree/bindings/media/i2c/ov8856.yaml | 22 ++-- > .../bindings/media/i2c/ovti,ov02a10.yaml | 29 ++--- > .../bindings/media/i2c/ovti,ov2680.yaml | 6 +- > .../bindings/media/i2c/ovti,ov772x.yaml | 9 +- > .../bindings/media/i2c/sony,imx214.yaml | 25 ++-- > .../bindings/media/i2c/sony,imx274.yaml | 3 +- > .../bindings/media/marvell,mmp2-ccic.yaml | 15 +-- > .../bindings/media/nxp,imx7-csi.yaml | 5 +- > .../bindings/media/nxp,imx7-mipi-csi2.yaml| 32 + > .../bindings/media/renesas,ceu.yaml | 17 +-- > .../bindings/media/renesas,csi2.yaml | 54 ++--- > .../bindings/media/renesas,vin.yaml | 113 +++--- > .../bindings/media/rockchip-isp1.yaml | 40 +-- > .../bindings/media/st,stm32-dcmi.yaml | 18 +-- > .../devicetree/bindings/media/ti,cal.yaml | 55 ++--- > .../bindings/media/xilinx/xlnx,csi2rxss.yaml | 39 +- > 26 files changed, 172 insertions(+), 599 deletions(-) -- Regards, Laurent Pinchart
[PATCH] arm64: PCI: Enable SMC conduit
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config accesses, this is a good place to
apply a firmware abstraction. The ARM PCI SMMCCC spec details a
standard SMC conduit designed to provide a simple PCI config
accessor. This specification enhances the existing ACPI/PCI
abstraction and expects power, config, etc functionality is handled
by the platform. It also is very explicit that the resulting config
space registers must behave as is specified by the pci specification.
Lets hook the normal ACPI/PCI config path, and when we detect
missing MADT data, attempt to probe the SMC conduit. If the conduit
exists and responds for the requested segment number (provided by the
ACPI namespace) attach a custom pci_ecam_ops which redirects
all config read/write requests to the firmware.
This patch is based on the Arm PCI Config space access document @
https://developer.arm.com/documentation/den0115/latest
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/pci.c | 87 +++
include/linux/arm-smccc.h | 26
2 files changed, 113 insertions(+)
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 1006ed2d7c60..56d3773aaa25 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -107,6 +108,90 @@ static int pci_acpi_root_prepare_resources(struct
acpi_pci_root_info *ci)
return status;
}
+static int smccc_pcie_check_conduit(u16 seg)
+{
+ struct arm_smccc_res res;
+
+ if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
+ return -EOPNOTSUPP;
+
+ arm_smccc_smc(SMCCC_PCI_VERSION, 0, 0, 0, 0, 0, 0, 0, );
+ if ((int)res.a0 < 0)
+ return -EOPNOTSUPP;
+
+ arm_smccc_smc(SMCCC_PCI_SEG_INFO, seg, 0, 0, 0, 0, 0, 0, );
+ if ((int)res.a0 < 0)
+ return -EOPNOTSUPP;
+
+ pr_info("PCI: SMC conduit attached to segment %d\n", seg);
+
+ return 0;
+}
+
+static int smccc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val)
+{
+ struct arm_smccc_res res;
+
+ devfn |= bus->number << 8;
+ devfn |= bus->domain_nr << 16;
+
+ arm_smccc_smc(SMCCC_PCI_READ, devfn, where, size, 0, 0, 0, 0, );
+ if (res.a0) {
+ *val = ~0;
+ return -PCIBIOS_BAD_REGISTER_NUMBER;
+ }
+
+ *val = res.a1;
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int smccc_pcie_config_write(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 val)
+{
+ struct arm_smccc_res res;
+
+ devfn |= bus->number << 8;
+ devfn |= bus->domain_nr << 16;
+
+ arm_smccc_smc(SMCCC_PCI_WRITE, devfn, where, size, val, 0, 0, 0, );
+ if (res.a0)
+ return -PCIBIOS_BAD_REGISTER_NUMBER;
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static const struct pci_ecam_ops smccc_pcie_ecam_ops = {
+ .bus_shift = 8,
+ .pci_ops= {
+ .read = smccc_pcie_config_read,
+ .write = smccc_pcie_config_write,
+ }
+};
+
+static struct pci_config_window *
+pci_acpi_setup_smccc_mapping(struct acpi_pci_root *root)
+{
+ struct device *dev = >device->dev;
+ struct resource *bus_res = >secondary;
+ struct pci_config_window *cfg;
+
+ cfg = kzalloc(sizeof(*cfg), GFP_KERNEL);
+ if (!cfg)
+ return ERR_PTR(-ENOMEM);
+
+ cfg->parent = dev;
+ cfg->ops = _pcie_ecam_ops;
+ cfg->busr.start = bus_res->start;
+ cfg->busr.end = bus_res->end;
+ cfg->busr.flags = IORESOURCE_BUS;
+
+ cfg->res.name = "PCI SMCCC";
+ if (cfg->ops->init)
+ cfg->ops->init(cfg);
+ return cfg;
+}
+
/*
* Lookup the bus range for the domain in MCFG, and set up config space
* mapping.
@@ -125,6 +210,8 @@ pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root)
ret = pci_mcfg_lookup(root, , _ops);
if (ret) {
+ if (!smccc_pcie_check_conduit(seg))
+ return pci_acpi_setup_smccc_mapping(root);
dev_err(dev, "%04x:%pR ECAM region not found\n", seg, bus_res);
return NULL;
}
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index f860645f6512..327f52533c71 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -89,6 +89,32 @@
#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED 1
+/* PCI ECAM conduit */
+#define SMCCC_PCI_VERSION \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32,\
+ ARM_SMCCC_OWNER_STANDARD, 0x0130)
+
+#define SMCCC_PCI_FEATURES
[PATCH net,stable v3] net: cdc_ncm: correct overhead in delayed_ndp_size
From: Jouni K. Seppänen
Aligning to tx_ndp_modulus is not sufficient because the next align
call can be cdc_ncm_align_tail, which can add up to ctx->tx_modulus +
ctx->tx_remainder - 1 bytes. This used to lead to occasional crashes
on a Huawei 909s-120 LTE module as follows:
- the condition marked /* if there is a remaining skb [...] */ is true
so the swaps happen
- skb_out is set from ctx->tx_curr_skb
- skb_out->len is exactly 0x3f52
- ctx->tx_curr_size is 0x4000 and delayed_ndp_size is 0xac
(note that the sum of skb_out->len and delayed_ndp_size is 0x3ffe)
- the for loop over n is executed once
- the cdc_ncm_align_tail call marked /* align beginning of next frame */
increases skb_out->len to 0x3f56 (the sum is now 0x4002)
- the condition marked /* check if we had enough room left [...] */ is
false so we break out of the loop
- the condition marked /* If requested, put NDP at end of frame. */ is
true so the NDP is written into skb_out
- now skb_out->len is 0x4002, so padding_count is minus two interpreted
as an unsigned number, which is used as the length argument to memset,
leading to a crash with various symptoms but usually including
> Call Trace:
>
> cdc_ncm_fill_tx_frame+0x83a/0x970 [cdc_ncm]
> cdc_mbim_tx_fixup+0x1d9/0x240 [cdc_mbim]
> usbnet_start_xmit+0x5d/0x720 [usbnet]
The cdc_ncm_align_tail call first aligns on a ctx->tx_modulus
boundary (adding at most ctx->tx_modulus-1 bytes), then adds
ctx->tx_remainder bytes. Alternatively, the next alignment call can
occur in cdc_ncm_ndp16 or cdc_ncm_ndp32, in which case at most
ctx->tx_ndp_modulus-1 bytes are added.
A similar problem has occurred before, and the code is nontrivial to
reason about, so add a guard before the crashing call. By that time it
is too late to prevent any memory corruption (we'll have written past
the end of the buffer already) but we can at least try to get a warning
written into an on-disk log by avoiding the hard crash caused by padding
past the buffer with a huge number of zeros.
Signed-off-by: Jouni K. Seppänen
Fixes: 4a0e3e989d66 ("cdc_ncm: Add support for moving NDP to end of NCM frame")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209407
Reported-by: kernel test robot
Reviewed-by: Bjørn Mork
---
v2: cast arguments to max() to same type, because otherwise integer
promotion can result in different types
v3: use max_t
drivers/net/usb/cdc_ncm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index e04f588538cc..d1346c50d237 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1199,7 +1199,10 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff
*skb, __le32 sign)
* accordingly. Otherwise, we should check here.
*/
if (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END)
- delayed_ndp_size = ALIGN(ctx->max_ndp_size,
ctx->tx_ndp_modulus);
+ delayed_ndp_size = ctx->max_ndp_size +
+ max_t(u32,
+ ctx->tx_ndp_modulus,
+ ctx->tx_modulus + ctx->tx_remainder) - 1;
else
delayed_ndp_size = 0;
@@ -1410,7 +1413,8 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff
*skb, __le32 sign)
if (!(dev->driver_info->flags & FLAG_SEND_ZLP) &&
skb_out->len > ctx->min_tx_pkt) {
padding_count = ctx->tx_curr_size - skb_out->len;
- skb_put_zero(skb_out, padding_count);
+ if (!WARN_ON(padding_count > ctx->tx_curr_size))
+ skb_put_zero(skb_out, padding_count);
} else if (skb_out->len < ctx->tx_curr_size &&
(skb_out->len % dev->maxpacket) == 0) {
skb_put_u8(skb_out, 0); /* force short packet */
--
2.20.1
Re: [PATCH v3 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on robh/for-next linus/master v5.11-rc2 next-20210104]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Maxime-Chevallier/media-i2c-Introduce-driver-for-the-TW9900-decoder/20201223-000948
base: git://linuxtv.org/media_tree.git master
config: arm64-randconfig-r001-20210105 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
5c951623bc8965fa1e89660f2f5f4a2944e4981a)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/cdf8ecd519454783c60d4bca02b9279f8133ef77
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Maxime-Chevallier/media-i2c-Introduce-driver-for-the-TW9900-decoder/20201223-000948
git checkout cdf8ecd519454783c60d4bca02b9279f8133ef77
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/media/i2c/tw9900.c:521:10: warning: variable 'ret' is uninitialized
>> when used here [-Wuninitialized]
return ret;
^~~
drivers/media/i2c/tw9900.c:505:9: note: initialize the variable 'ret' to
silence this warning
int ret;
^
= 0
1 warning generated.
vim +/ret +521 drivers/media/i2c/tw9900.c
498
499 static int tw9900_probe(struct i2c_client *client,
500 const struct i2c_device_id *id)
501 {
502 struct device *dev = >dev;
503 struct v4l2_ctrl_handler *hdl;
504 struct tw9900 *tw9900;
505 int ret;
506
507 tw9900 = devm_kzalloc(dev, sizeof(*tw9900), GFP_KERNEL);
508 if (!tw9900)
509 return -ENOMEM;
510
511 tw9900->client = client;
512 tw9900->cur_mode = _modes[0];
513
514 tw9900->reset_gpio = devm_gpiod_get(dev, "reset",
GPIOD_OUT_LOW);
515 if (IS_ERR(tw9900->reset_gpio))
516 tw9900->reset_gpio = NULL;
517
518 tw9900->regulator = devm_regulator_get(>client->dev,
"vdd");
519 if (IS_ERR(tw9900->regulator)) {
520 dev_err(dev, "Failed to get power regulator\n");
> 521 return ret;
522 }
523
524 v4l2_i2c_subdev_init(>subdev, client,
_subdev_ops);
525 tw9900->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE |
526 V4L2_SUBDEV_FL_HAS_EVENTS;
527
528 hdl = >hdl;
529
530 v4l2_ctrl_handler_init(hdl, 2);
531
532 v4l2_ctrl_new_std(hdl, _ctrl_ops, V4L2_CID_BRIGHTNESS,
533-128, 127, 1, 0);
534 v4l2_ctrl_new_std(hdl, _ctrl_ops, V4L2_CID_CONTRAST,
5350, 255, 1, 0x60);
536
537 tw9900->subdev.ctrl_handler = hdl;
538 if (hdl->error) {
539 int err = hdl->error;
540
541 v4l2_ctrl_handler_free(hdl);
542 return err;
543 }
544
545 ret = tw9900_power_on(tw9900);
546 if (ret)
547 return ret;
548
549 ret = tw9900_check_id(tw9900, client);
550 if (ret)
551 goto err_power_off;
552
553 tw9900->subdev.internal_ops = _internal_ops;
554 tw9900->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
555 tw9900->pad.flags = MEDIA_PAD_FL_SOURCE;
556 tw9900->subdev.entity.function = MEDIA_ENT_F_DV_DECODER;
557
558 ret = media_entity_pads_init(>subdev.entity, 1,
>pad);
559 if (ret < 0)
560 goto err_power_off;
561
562 ret = v4l2_async_register_subdev(>subdev);
563 if (ret) {
564 dev_err(dev, "v4l2 async register subdev failed\n");
565 goto err_clean_entity;
566 }
567
568 pm_runtime_set_active(dev);
569 pm_ru
回复: KASAN: use-after-free Read in service_outstanding_interrupt
发件人: Oliver Neukum
发送时间: 2021年1月5日 0:28
收件人: syzbot; andreyk...@google.com; gre...@linuxfoundation.org;
gustavo...@kernel.org; ingras...@epigenesys.com; lee.jo...@linaro.org;
linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
penguin-ker...@i-love.sakura.ne.jp; syzkaller-b...@googlegroups.com
主题: Re: KASAN: use-after-free Read in service_outstanding_interrupt
Am Donnerstag, den 17.12.2020, 19:21 -0800 schrieb syzbot:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g..
> git tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> console output: https://syzkaller.appspot.com/x/log.txt?x=12c5b62350
> kernel config: https://syzkaller.appspot.com/x/.config?x=5cea7506b7139727
> dashboard link: https://syzkaller.appspot.com/bug?extid=9e04e2df4a32fb661daf
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175adf0750
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1672680f50
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: >syzbot+9e04e2df4a32fb661...@syzkaller.appspotmail.com
>
>#syz test: https://github.com/google/kasan.git 5e60366d
>
Hello Oliver
this use-after-free still exists，It can be seen from calltrace that it is
usb_device's object has been released when disconnect,
can add a reference count to usb_device's object to avoid this problem
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 508b1c3f8b73..001cb93da6bf 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -106,6 +106,7 @@ struct wdm_device {
struct list_headdevice_list;
int (*manage_power)(struct usb_interface *, int);
+ struct usb_device *usb_dev;
};
static struct usb_driver wdm_driver;
@@ -338,6 +339,7 @@ static void free_urbs(struct wdm_device *desc)
static void cleanup(struct wdm_device *desc)
{
+ usb_put_dev(desc->usb_dev);
kfree(desc->sbuf);
kfree(desc->inbuf);
kfree(desc->orq);
@@ -855,6 +857,7 @@ static int wdm_create(struct usb_interface *intf, struct
usb_endpoint_descripto
r
desc->intf = intf;
INIT_WORK(>rxwork, wdm_rxwork);
INIT_WORK(>service_outs_intr, service_interrupt_work);
+ desc->usb_dev = usb_get_dev(interface_to_usbdev(intf));
rv = -EINVAL;
if (!usb_endpoint_is_int_in(ep))
>From f51e3c5a202f3abc805edd64b21a68d29dd9d60e Mon Sep 17 >00:00:00 2001
>From: Oliver Neukum
>Date: Mon, 4 Jan 2021 17:26:33 +0100
>Subject: [PATCH] cdc-wdm: poison URBs upon disconnect
>
>We have a chicken and egg issue between interrupt and work.
>This should break the cycle.
>
>Signed-off-by: Oliver Neukum
>---
>drivers/usb/class/cdc-wdm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc->wdm.c
>index 02d0cfd23bb2..14eddda35280 100644
>--- a/drivers/usb/class/cdc-wdm.c
>+++ b/drivers/usb/class/cdc-wdm.c
>@@ -324,9 +324,9 @@ static void wdm_int_callback(struct urb *urb)
>static void kill_urbs(struct wdm_device *desc)
> {
> /* the order here is essential */
>- usb_kill_urb(desc->command);
>- usb_kill_urb(desc->validity);
>- usb_kill_urb(desc->response);
>+ usb_poison_urb(desc->command);
>+ usb_poison_urb(desc->validity);
>+ usb_poison_urb(desc->response);
> }
>
> static void free_urbs(struct wdm_device *desc)
>--
>2.26.2
Re: [PATCH] bcache: consider the fragmentation when update the writeback rate
On 1/5/21 11:44 AM, Dongdong Tao wrote: > Hey Coly, > > This is the second version of the patch, please allow me to explain a > bit for this patch: > > We accelerate the rate in 3 stages with different aggressiveness, the > first stage starts when dirty buckets percent reach above > BCH_WRITEBACK_FRAGMENT_THRESHOLD_LOW(50), the second is > BCH_WRITEBACK_FRAGMENT_THRESHOLD_MID(57) and the third is > BCH_WRITEBACK_FRAGMENT_THRESHOLD_HIGH(64). By default the first stage > tries to writeback the amount of dirty data in one bucket (on average) > in (1 / (dirty_buckets_percent - 50)) second, the second stage tries to > writeback the amount of dirty data in one bucket in (1 / > (dirty_buckets_percent - 57)) * 200 millisecond. The third stage tries > to writeback the amount of dirty data in one bucket in (1 / > (dirty_buckets_percent - 64)) * 20 millisecond. > > As we can see, there are two writeback aggressiveness increasing > strategies, one strategy is with the increasing of the stage, the first > stage is the easy-going phase whose initial rate is trying to write back > dirty data of one bucket in 1 second, the second stage is a bit more > aggressive, the initial rate tries to writeback the dirty data of one > bucket in 200 ms, the last stage is even more, whose initial rate tries > to writeback the dirty data of one bucket in 20 ms. This makes sense, > one reason is that if the preceding stage couldn’t get the fragmentation > to a fine stage, then the next stage should increase the aggressiveness > properly, also it is because the later stage is closer to the > bch_cutoff_writeback_sync. Another aggressiveness increasing strategy is > with the increasing of dirty bucket percent within each stage, the first > strategy controls the initial writeback rate of each stage, while this > one increases the rate based on the initial rate, which is initial_rate > * (dirty bucket percent - BCH_WRITEBACK_FRAGMENT_THRESHOLD_X). > > The initial rate can be controlled by 3 parameters > writeback_rate_fp_term_low, writeback_rate_fp_term_mid, > writeback_rate_fp_term_high, they are default 1, 5, 50, users can adjust > them based on their needs. > > The reason that I choose 50, 57, 64 as the threshold value is because > the GC must be triggered at least once during each stage due to the > “sectors_to_gc” being set to 1/16 (6.25 %) of the total cache size. So, > the hope is that the first and second stage can get us back to good > shape in most situations by smoothly writing back the dirty data without > giving too much stress to the backing devices, but it might still enter > the third stage if the bucket consumption is very aggressive. > > This patch use (dirty / dirty_buckets) * fp_term to calculate the rate, > this formula means that we want to writeback (dirty / dirty_buckets) in > 1/fp_term second, fp_term is calculated by above aggressiveness > controller, “dirty” is the current dirty sectors, “dirty_buckets” is the > current dirty buckets, so (dirty / dirty_buckets) means the average > dirty sectors in one bucket, the value is between 0 to 1024 for the > default setting, so this formula basically gives a hint that to reclaim > one bucket in 1/fp_term second. By using this semantic, we can have a > lower writeback rate when the amount of dirty data is decreasing and > overcome the fact that dirty buckets number is always increasing unless > GC happens. > > *Compare to the first patch: > *The first patch is trying to write back all the data in 40 seconds, > this will result in a very high writeback rate when the amount of dirty > data is big, this is mostly true for the large cache devices. The basic > problem is that the semantic of this patch is not ideal, because we > don’t really need to writeback all dirty data in order to solve this > issue, and the instant large increase of the rate is something I feel we > should better avoid (I like things to be smoothly changed unless no > choice: )). > > Before I get to this new patch(which I believe should be optimal for me > atm), there have been many tuning/testing iterations, eg. I’ve tried to > tune the algorithm to writeback ⅓ of the dirty data in a certain amount > of seconds, writeback 1/fragment of the dirty data in a certain amount > of seconds, writeback all the dirty data only in those error_buckets > (error buckets = dirty buckets - 50% of the total buckets) in a certain > amount of time. However, those all turn out not to be ideal, only the > semantic of the patch makes much sense for me and allows me to control > the rate in a more precise way. > > *Testing data: > *I'll provide the visualized testing data in the next couple of days > with 1TB NVME devices cache but with HDD as backing device since it's > what we mostly used in production env. > I have the data for 400GB NVME, let me prepare it and take it for you to > review. [snipped] Hi Dongdong, Thanks for the update and continuous effort on this idea. Please keep in mind the writeback rate is
Re: [PATCH 30/31] PM / devfreq: exynos: convert to use devm_pm_opp_* API
On Sun, Jan 3, 2021 at 12:59 PM Yangtao Li wrote:
>
> Use devm_pm_opp_* API to simplify code, and remove opp_table
> from exynos_bus.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/devfreq/exynos-bus.c | 42
> 1 file changed, 9 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index e689101abc93..51752e5ce980 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -33,7 +33,6 @@ struct exynos_bus {
>
> unsigned long curr_freq;
>
> - struct opp_table *opp_table;
> struct clk *clk;
> unsigned int ratio;
> };
> @@ -159,10 +158,7 @@ static void exynos_bus_exit(struct device *dev)
>
> platform_device_unregister(bus->icc_pdev);
>
> - dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> - dev_pm_opp_put_regulators(bus->opp_table);
OPP uses the clock and regulator. It means that there are dependency
between them and the sequence for resource free.
I think that OPP should be removed before clock and regulator.
Your patch always guarantee this dependency? If not, we have to
free the resource according to the dependency.
> - bus->opp_table = NULL;
> }
>
> static void exynos_bus_passive_exit(struct device *dev)
> @@ -171,7 +167,6 @@ static void exynos_bus_passive_exit(struct device *dev)
>
> platform_device_unregister(bus->icc_pdev);
>
> - dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> }
>
> @@ -183,15 +178,13 @@ static int exynos_bus_parent_parse_of(struct
> device_node *np,
> const char *vdd = "vdd";
> int i, ret, count, size;
>
> - opp_table = dev_pm_opp_set_regulators(dev, , 1);
> + opp_table = devm_pm_opp_set_regulators(dev, , 1);
> if (IS_ERR(opp_table)) {
> ret = PTR_ERR(opp_table);
> dev_err(dev, "failed to set regulators %d\n", ret);
> return ret;
> }
>
> - bus->opp_table = opp_table;
> -
> /*
> * Get the devfreq-event devices to get the current utilization of
> * buses. This raw data will be used in devfreq ondemand governor.
> @@ -199,25 +192,20 @@ static int exynos_bus_parent_parse_of(struct
> device_node *np,
> count = devfreq_event_get_edev_count(dev, "devfreq-events");
> if (count < 0) {
> dev_err(dev, "failed to get the count of devfreq-event
> dev\n");
> - ret = count;
> - goto err_regulator;
> + return count;
> }
> bus->edev_count = count;
>
> size = sizeof(*bus->edev) * count;
> bus->edev = devm_kzalloc(dev, size, GFP_KERNEL);
> - if (!bus->edev) {
> - ret = -ENOMEM;
> - goto err_regulator;
> - }
> + if (!bus->edev)
> + return -ENOMEM;
>
> for (i = 0; i < count; i++) {
> bus->edev[i] = devfreq_event_get_edev_by_phandle(dev,
> "devfreq-events", i);
> - if (IS_ERR(bus->edev[i])) {
> - ret = -EPROBE_DEFER;
> - goto err_regulator;
> - }
> + if (IS_ERR(bus->edev[i]))
> + return -EPROBE_DEFER;
> }
>
> /*
> @@ -234,12 +222,6 @@ static int exynos_bus_parent_parse_of(struct device_node
> *np,
> bus->ratio = DEFAULT_SATURATION_RATIO;
>
> return 0;
> -
> -err_regulator:
> - dev_pm_opp_put_regulators(bus->opp_table);
> - bus->opp_table = NULL;
> -
> - return ret;
> }
>
> static int exynos_bus_parse_of(struct device_node *np,
> @@ -264,7 +246,7 @@ static int exynos_bus_parse_of(struct device_node *np,
> }
>
> /* Get the freq and voltage from OPP table to scale the bus freq */
> - ret = dev_pm_opp_of_add_table(dev);
> + ret = devm_pm_opp_of_add_table(dev);
> if (ret < 0) {
> dev_err(dev, "failed to get OPP table\n");
> goto err_clk;
> @@ -276,15 +258,13 @@ static int exynos_bus_parse_of(struct device_node *np,
> if (IS_ERR(opp)) {
> dev_err(dev, "failed to find dev_pm_opp\n");
> ret = PTR_ERR(opp);
> - goto err_opp;
> + goto err_clk;
> }
> bus->curr_freq = dev_pm_opp_get_freq(opp);
> dev_pm_opp_put(opp);
>
> return 0;
>
> -err_opp:
> - dev_pm_opp_of_remove_table(dev);
> err_clk:
> clk_disable_unprepare(bus->clk);
>
> @@ -425,7 +405,7 @@ static int exynos_bus_probe(struct platform_device *pdev)
> /* Parse the device-tree to get the resource information */
> ret = exynos_bus_parse_of(np, bus);
> if (ret < 0)
> - goto err_reg;
> + return ret;
>
> if (passive)
> ret =
RE: [PATCH] drivers core: Free dma_range_map when driver probe failed
> -Original Message- > From: Jim Quinlan > Sent: Monday, January 4, 2021 11:56 PM > To: Jim Quinlan ; Li, Meng > ; open list > Cc: Greg Kroah-Hartman ; raf...@kernel.org; > Hao, Kexin ; Jim Quinlan > ; Christoph Hellwig > Subject: Re: [PATCH] drivers core: Free dma_range_map when driver probe > failed > > > Subject: [PATCH] drivers core: Free dma_range_map when driver probe > > failed > > > > There will be memory leak if driver probe failed. Trace as below: > > backtrace: > > [<2415258f>] kmemleak_alloc+0x3c/0x50 > > [] __kmalloc+0x208/0x530 > > [<48bc7b3a>] of_dma_get_range+0xe4/0x1b0 > > [<41e39065>] of_dma_configure_id+0x58/0x27c > > [<6356866a>] platform_dma_configure+0x2c/0x40 > > .. > > [<0afcf9b5>] ret_from_fork+0x10/0x3c > > > > This issue is introduced by commit e0d072782c73("dma-mapping: > > introduce DMA range map, supplanting dma_pfn_offset "). It doesn't > > free dma_range_map when driver probe failed and cause above memory > > leak. So, add code to free it in error path. > > > > Fixes: e0d072782c73("dma-mapping: introduce DMA range map, > supplanting > > dma_pfn_offset ") > > Cc: sta...@vger.kernel.org > > Signed-off-by: Meng Li > > --- > > drivers/base/dd.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/base/dd.c b/drivers/base/dd.c index > > 148e81969e04..8e4871aa34bc 100644 > > --- a/drivers/base/dd.c > > +++ b/drivers/base/dd.c > > @@ -612,6 +612,7 @@ static int really_probe(struct device *dev, struct > > device_driver *drv) > > else if (drv->remove) > > drv->remove(dev); > > probe_failed: > > + kfree(dev->dma_range_map); > > if (dev->bus) > > blocking_notifier_call_chain(>bus->p->bus_notifier, > > > > BUS_NOTIFY_DRIVER_NOT_BOUND, dev); > > -- > > 2.17.1 > > > > -- > > Hi Meng, > > Sorry for the delay -- I was on vacation. I agree with you -- thanks. > However, note that in function device_release() in drivers/base/core.c > there is this line: > > kfree(dev->dma_range_map); > > Won't this also be called if all of the appropriate drivers' probes fail for > this > device, effecting a double kfree? Perhaps your patch could also set "dev- > >dma_range_map" to NULL after calling kfree()? > Hi Jim, Please discard my previous reply, because I had a misunderstand about what you suggested. I agree with you total, and I will set dma_range_map as NULL in really_probe() function when driver probe failed. I will sent V2 patch. Thanks, Limeng > Thanks much, > Jim Quinlan > Broadcom STB
Re: mmotm 2021-01-04-16-56 uploaded (drivers/power/supply/max8997_charger.c)
On 1/4/21 4:57 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2021-01-04-16-56 has been uploaded to > >https://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > https://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > > You will need quilt to apply these patches to the latest Linus release (5.x > or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > https://ozlabs.org/~akpm/mmotm/series > > The file broken-out.tar.gz contains two datestamp files: .DATE and > .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, > followed by the base kernel version against which this patch series is to > be applied. > > This tree is partially included in linux-next. To see which patches are > included in linux-next, consult the `series' file. Only the patches > within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in > linux-next. Hi, Commit bb118e5178b3 in linux-next seems to introduce a few build problems: ld: drivers/power/supply/max8997_charger.o: in function `max8997_battery_extcon_evt_worker': max8997_charger.c:(.text+0xa3): undefined reference to `extcon_get_state' ld: max8997_charger.c:(.text+0x102): undefined reference to `extcon_get_state' ld: max8997_charger.c:(.text+0x161): undefined reference to `extcon_get_state' ld: max8997_charger.c:(.text+0x1c0): undefined reference to `extcon_get_state' ld: max8997_charger.c:(.text+0x21f): undefined reference to `extcon_get_state' ld: drivers/power/supply/max8997_charger.o: in function `max8997_battery_probe': max8997_charger.c:(.text+0x962): undefined reference to `extcon_get_edev_by_phandle' ld: max8997_charger.c:(.text+0xab0): undefined reference to `devm_extcon_register_notifier_all' CONFIG_EXTCON=m CONFIG_CHARGER_MAX8997=y Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap config-r7006.gz Description: application/gzip
