6.8.8-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 138/158 mm/shmem: inline shmem_is_huge() for disabled transparent hugepages
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sumanth Korikkar <[email protected]>
commit 1f737846aa3c45f07a06fa0d018b39e1afb8084a upstream.
In order to minimize code size (CONFIG_CC_OPTIMIZE_FOR_SIZE=y), compiler might choose to make a regular function call (out-of-line) for shmem_is_huge() instead of inlining it. When transparent hugepages are disabled (CONFIG_TRANSPARENT_HUGEPAGE=n), it can cause compilation error.
mm/shmem.c: In function `shmem_getattr':./include/linux/huge_mm.h:383:27: note: in expansion of macro `BUILD_BUG'
383 | #define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
| ^~~~~~~~~
mm/shmem.c:1148:33: note: in expansion of macro `HPAGE_PMD_SIZE'
1148 | stat->blksize = HPAGE_PMD_SIZE;
To prevent the possible error, always inline shmem_is_huge() when transparent hugepages are disabled.
--- include/linux/shmem_fs.h | 9 +++++++++ mm/shmem.c | 6 ------ 2 files changed, 9 insertions(+), 6 deletions(-)
include/linux/shmem_fs.h +9 -0
@@ -114,8 +114,17 @@ extern struct page *shmem_read_mapping_pextern void shmem_truncate_range (struct inode *inode,loff_t start,loff_t end);int shmem_unuse (unsigned int type); +#ifdef CONFIG_TRANSPARENT_HUGEPAGE extern bool shmem_is_huge (struct inode *inode,pgoff_t index,bool shmem_huge_force,struct mm_struct *mm,unsigned long vm_flags); +#else +static __always_inline bool shmem_is_huge(struct inode *inode, pgoff_t index, bool shmem_huge_force, +struct mm_struct *mm,unsigned long vm_flags) +{ +return false; +} +#endif +#ifdef CONFIG_SHMEM extern unsigned long shmem_swap_usage (struct vm_area_struct *vma);#else
mm/shmem.c +0 -6
@@ -742,12 +742,6 @@ static long shmem_unused_huge_count(stru#define shmem_huge SHMEM_HUGE_DENY -bool shmem_is_huge (struct inode *inode,pgoff_t index,bool shmem_huge_force, -struct mm_struct *mm,unsigned long vm_flags) -{ -return false; -} -static unsigned long shmem_unused_huge_shrink (struct shmem_sb_info *sbinfo,struct shrink_control *sc,unsigned long nr_to_split) {
Greg Kroah-Hartman
maintainerPATCH 139/158 fuse: fix leaked ENOSYS error on first statx call
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Danny Lin <[email protected]>
commit eb4b691b9115fae4c844f5941418335575cf667f upstream.
FUSE attempts to detect server support for statx by trying it once and setting no_statx=1 if it fails with ENOSYS, but consider the following scenario:
- Userspace (e.g. sh) calls stat() on a file
* succeeds
- Userspace (e.g. lsd) calls statx(BTIME) on the same file
- request_mask = STATX_BASIC_STATS | STATX_BTIME
- first pass: sync=true due to differing cache_mask
- statx fails and returns ENOSYS
- set no_statx and retry
- retry sets mask = STATX_BASIC_STATS
- now mask == cache_mask; sync=false (time_before: still valid)
- so we take the "else if (stat)" path
- "err" is still ENOSYS from the failed statx call
Fix this by zeroing "err" before retrying the failed call.
--- fs/fuse/dir.c | 1 + 1 file changed, 1 insertion(+)
fs/fuse/dir.c +1 -0
@@ -1317,6 +1317,7 @@ retry: err =fuse_do_statx (inode, file, stat);if (err == -ENOSYS ) { fc->no_statx =1 ; + err =0 ; goto retry; } }else {
Greg Kroah-Hartman
maintainerPATCH 140/158 drm/amdgpu: validate the parameters of bo mapping operations more clearly
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: xinhui pan <[email protected]>
commit 6fef2d4c00b5b8561ad68dd2b68173f5c6af1e75 upstream.
Verify the parameters of amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 72 +++++++++++++++++++++------------ 1 file changed, 46 insertions(+), 26 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +46 -26
@@ -1559,6 +1559,37 @@ static void amdgpu_vm_bo_insert_map(strutrace_amdgpu_vm_bo_map (bo_va, mapping); } +/* Validate operation parameters to prevent potential abuse */ +static int amdgpu_vm_verify_parameters (struct amdgpu_device *adev, +struct amdgpu_bo *bo, +uint64_t saddr, +uint64_t offset, +uint64_t size) +{ +uint64_t tmp, lpfn; + +if (saddr &AMDGPU_GPU_PAGE_MASK + || offset &AMDGPU_GPU_PAGE_MASK + || size &AMDGPU_GPU_PAGE_MASK ) +return -EINVAL ; + +if (check_add_overflow (saddr, size, &tmp) + ||check_add_overflow (offset, size, &tmp) + || size ==0 /* which also leads to end < begin */ ) +return -EINVAL ; + +/* make sure object fit at this offset */ +if (bo && offset + size >amdgpu_bo_size (bo)) +return -EINVAL ; + +/* Ensure last pfn not exceed max_pfn */ + lpfn = (saddr + size -1 ) >>AMDGPU_GPU_PAGE_SHIFT ; +if (lpfn >= adev->vm_manager.max_pfn) +return -EINVAL ; + +return 0 ; +} +/** * amdgpu_vm_bo_map - map bo inside a vm *
@@ -1585,21 +1616,14 @@ int amdgpu_vm_bo_map(struct amdgpu_devicstruct amdgpu_bo *bo = bo_va->base.bo;struct amdgpu_vm *vm = bo_va->base.vm;uint64_t eaddr; +int r; -/* validate the parameters */ -if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || size & ~PAGE_MASK ) -return -EINVAL ; -if (saddr + size <= saddr || offset + size <= offset) -return -EINVAL ; - -/* make sure object fit at this offset */ - eaddr = saddr + size -1 ; -if ((bo && offset + size >amdgpu_bo_size (bo)) || - (eaddr >= adev->vm_manager.max_pfn <<AMDGPU_GPU_PAGE_SHIFT )) -return -EINVAL ; + r =amdgpu_vm_verify_parameters (adev, bo, saddr, offset, size); +if (r) +return r; saddr /=AMDGPU_GPU_PAGE_SIZE ; - eaddr /=AMDGPU_GPU_PAGE_SIZE ; + eaddr = saddr + (size -1 ) /AMDGPU_GPU_PAGE_SIZE ; tmp =amdgpu_vm_it_iter_first (&vm->va, saddr, eaddr);if (tmp) {
@@ -1652,17 +1676,9 @@ int amdgpu_vm_bo_replace_map(struct amdguint64_t eaddr;int r; -/* validate the parameters */ -if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || size & ~PAGE_MASK ) -return -EINVAL ; -if (saddr + size <= saddr || offset + size <= offset) -return -EINVAL ; - -/* make sure object fit at this offset */ - eaddr = saddr + size -1 ; -if ((bo && offset + size >amdgpu_bo_size (bo)) || - (eaddr >= adev->vm_manager.max_pfn <<AMDGPU_GPU_PAGE_SHIFT )) -return -EINVAL ; + r =amdgpu_vm_verify_parameters (adev, bo, saddr, offset, size); +if (r) +return r;/* Allocate all the needed memory */ mapping =kmalloc (sizeof (*mapping),GFP_KERNEL );
@@ -1676,7 +1692,7 @@ int amdgpu_vm_bo_replace_map(struct amdg } saddr /=AMDGPU_GPU_PAGE_SIZE ; - eaddr /=AMDGPU_GPU_PAGE_SIZE ; + eaddr = saddr + (size -1 ) /AMDGPU_GPU_PAGE_SIZE ; mapping->start = saddr; mapping->last = eaddr;
@@ -1763,10 +1779,14 @@ int amdgpu_vm_bo_clear_mappings(struct astruct amdgpu_bo_va_mapping *before, *after, *tmp, *next;LIST_HEAD (removed);uint64_t eaddr; +int r; + + r =amdgpu_vm_verify_parameters (adev,NULL , saddr,0 , size); +if (r) +return r; - eaddr = saddr + size -1 ; saddr /=AMDGPU_GPU_PAGE_SIZE ; - eaddr /=AMDGPU_GPU_PAGE_SIZE ; + eaddr = saddr + (size -1 ) /AMDGPU_GPU_PAGE_SIZE ;/* Allocate all the needed memory */ before =kzalloc (sizeof (*before),GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 141/158 drm/amdkfd: Fix memory leak in create_process failure
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Kuehling <[email protected]>
commit 18921b205012568b45760753ad3146ddb9e2d4e2 upstream.
Fix memory leak due to a leaked mmget reference on an error handling code path that is triggered when attempting to create KFD processes while a GPU reset is in progress.
--- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdkfd/kfd_process.c +2 -2
@@ -819,9 +819,9 @@ struct kfd_process *kfd_create_process(smutex_lock (&kfd_processes_mutex);if (kfd_is_locked ()) { -mutex_unlock (&kfd_processes_mutex);pr_debug ("KFD is locked! Cannot create process" ); -return ERR_PTR (-EINVAL ); + process =ERR_PTR (-EINVAL ); + goto out; }/* A prior open of /dev/kfd could have already created the process. */
Greg Kroah-Hartman
maintainerPATCH 142/158 drm/amdgpu: remove invalid resource->start check v2
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian König <[email protected]>
commit ca7c4507ba87e9fc22e0ecfa819c3664b3e8287b upstream.
The majority of those where removed in the commit aed01a68047b ("drm/amdgpu: Remove TTM resource->start visible VRAM condition v2")
But this one was missed because it's working on the resource and not the BO. Since we also no longer use a fake start address for visible BOs this will now trigger invalid mapping errors.
v2: also remove the unused variable
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +0 -4
@@ -562,7 +562,6 @@ static int amdgpu_ttm_io_mem_reserve(str struct ttm_resource *mem) {struct amdgpu_device *adev =amdgpu_ttm_adev (bdev); -size_t bus_size = (size_t )mem->size;switch (mem->mem_type) {case TTM_PL_SYSTEM :
@@ -573,9 +572,6 @@ static int amdgpu_ttm_io_mem_reserve(strbreak ;case TTM_PL_VRAM : mem->bus.offset = mem->start <<PAGE_SHIFT ; -/* check if it's visible */ -if ((mem->bus.offset + bus_size) > adev->gmc.visible_vram_size) -return -EINVAL ;if (adev->mman.aper_base_kaddr && mem->placement &TTM_PL_FLAG_CONTIGUOUS )
Greg Kroah-Hartman
maintainerPATCH 143/158 drm/ttm: stop pooling cached NUMA pages v2
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian König <[email protected]>
commit b6976f323a8687cc0d55bc92c2086fd934324ed5 upstream.
We only pool write combined and uncached allocations because they require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary overhead, but also that under memory pressure it can happen that pages from the wrong NUMA node enters the pool and are re-used over and over again.
This can lead to performance reduction after running into memory pressure.
v2: restructure and cleanup the code a bit from the internal hack to
test this.
--- drivers/gpu/drm/ttm/ttm_pool.c | 38 ++++++++++++++++++++++++++++---------- 1 file changed, 28 insertions(+), 10 deletions(-)
drivers/gpu/drm/ttm/ttm_pool.c +28 -10
@@ -288,17 +288,23 @@ static struct ttm_pool_type *ttm_pool_se enum ttm_caching caching, unsigned int order) { - if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) + if (pool->use_dma_alloc) return &pool->caching[caching].orders[order]; #ifdef CONFIG_X86 switch (caching) { case ttm_write_combined: + if (pool->nid != NUMA_NO_NODE) + return &pool->caching[caching].orders[order]; + if (pool->use_dma32) return &global_dma32_write_combined[order]; return &global_write_combined[order]; case ttm_uncached: + if (pool->nid != NUMA_NO_NODE) + return &pool->caching[caching].orders[order]; + if (pool->use_dma32) return &global_dma32_uncached[order];
@@ -566,11 +572,17 @@ void ttm_pool_init(struct ttm_pool *pool pool->use_dma_alloc = use_dma_alloc; pool->use_dma32 = use_dma32; -if (use_dma_alloc || nid !=NUMA_NO_NODE ) { -for (i =0 ; i <TTM_NUM_CACHING_TYPES ; ++i) -for (j =0 ; j <NR_PAGE_ORDERS ; ++j) -ttm_pool_type_init (&pool->caching[i].orders[j], - pool, i, j); +for (i =0 ; i <TTM_NUM_CACHING_TYPES ; ++i) { +for (j =0 ; j <NR_PAGE_ORDERS ; ++j) { +struct ttm_pool_type *pt; + +/* Initialize only pool types which are actually used */ + pt =ttm_pool_select_type (pool, i, j); +if (pt != &pool->caching[i].orders[j]) +continue ; + +ttm_pool_type_init (pt, pool, i, j); + } } }EXPORT_SYMBOL (ttm_pool_init);
@@ -599,10 +611,16 @@ void ttm_pool_fini(struct ttm_pool *pool {unsigned int i, j; -if (pool->use_dma_alloc || pool->nid !=NUMA_NO_NODE ) { -for (i =0 ; i <TTM_NUM_CACHING_TYPES ; ++i) -for (j =0 ; j <NR_PAGE_ORDERS ; ++j) -ttm_pool_type_fini (&pool->caching[i].orders[j]); +for (i =0 ; i <TTM_NUM_CACHING_TYPES ; ++i) { +for (j =0 ; j <NR_PAGE_ORDERS ; ++j) { +struct ttm_pool_type *pt; + + pt =ttm_pool_select_type (pool, i, j); +if (pt != &pool->caching[i].orders[j]) +continue ; + +ttm_pool_type_fini (pt); + } }/* We removed the pool types from the LRU, but we need to also make sure
Greg Kroah-Hartman
maintainerPATCH 144/158 drm/xe: Fix bo leak in intel_fb_bo_framebuffer_init
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maarten Lankhorst <[email protected]>
commit 652ead9b746a63e4e79d7ad66d3edf0a8a5b0c2f upstream.
Add a unreference bo in the error path, to prevent leaking a bo ref.
Return 0 on success to clarify the success path.
--- drivers/gpu/drm/xe/display/intel_fb_bo.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/display/intel_fb_bo.c +6 -2
@@ -31,7 +31,7 @@ int intel_fb_bo_framebuffer_init(struct intel_framebuffer *intel_fb, ret =ttm_bo_reserve (&bo->ttm, true, false,NULL );if (ret) -return ret; + goto err;if (!(bo->flags &XE_BO_SCANOUT_BIT )) {/*
@@ -42,12 +42,16 @@ int intel_fb_bo_framebuffer_init(struct intel_framebuffer *intel_fb,*/ if (XE_IOCTL_DBG (i915, !list_empty (&bo->ttm.base.gpuva.list))) {ttm_bo_unreserve (&bo->ttm); -return -EINVAL ; + ret = -EINVAL ; + goto err; } bo->flags |=XE_BO_SCANOUT_BIT ; }ttm_bo_unreserve (&bo->ttm); +return 0 ; +err: +xe_bo_put (bo);return ret; }
Signature · 1 line
2.44.0
Greg Kroah-Hartman
maintainerPATCH 145/158 drm/vmwgfx: Fix prime import/export
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zack Rusin <[email protected]>
commit b32233accefff1338806f064fb9b62cf5bc0609f upstream.
vmwgfx never supported prime import of external buffers. Furthermore the driver exposes two different objects to userspace: vmw_surface's and gem buffers but prime import/export only worked with vmw_surfaces.
Because gem buffers are used through the dumb_buffer interface this meant that the driver created buffers couldn't have been prime exported or imported.
Fix prime import/export. Makes IGT's kms_prime pass.
--- drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 35 +++++++++++++++++++++-- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 7 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_bo.h | 2 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 3 + drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 32 +++++++++++++++++++++ drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 15 ++++++++- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 44 +++++++++++++++++++---------- 8 files changed, 117 insertions(+), 22 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c +32 -3
@@ -456,8 +456,10 @@ int vmw_bo_cpu_blit(struct ttm_buffer_ob .no_wait_gpu = false };u32 j, initial_line = dst_offset / dst_stride; -struct vmw_bo_blit_line_data d; +struct vmw_bo_blit_line_data d = {0 };int ret =0 ; +struct page **dst_pages =NULL ; +struct page **src_pages =NULL ;/* Buffer objects need to be either pinned or reserved: */ if (!(dst->pin_count))
@@ -477,12 +479,35 @@ int vmw_bo_cpu_blit(struct ttm_buffer_obreturn ret; } +if (!src->ttm->pages && src->ttm->sg) { + src_pages =kvmalloc_array (src->ttm->num_pages, +sizeof (struct page *),GFP_KERNEL ); +if (!src_pages) +return -ENOMEM ; + ret =drm_prime_sg_to_page_array (src->ttm->sg, src_pages, + src->ttm->num_pages); +if (ret) + goto out; + } +if (!dst->ttm->pages && dst->ttm->sg) { + dst_pages =kvmalloc_array (dst->ttm->num_pages, +sizeof (struct page *),GFP_KERNEL ); +if (!dst_pages) { + ret = -ENOMEM ; + goto out; + } + ret =drm_prime_sg_to_page_array (dst->ttm->sg, dst_pages, + dst->ttm->num_pages); +if (ret) + goto out; + } + d.mapped_dst =0 ; d.mapped_src =0 ; d.dst_addr =NULL ; d.src_addr =NULL ; - d.dst_pages = dst->ttm->pages; - d.src_pages = src->ttm->pages; + d.dst_pages = dst->ttm->pages ? dst->ttm->pages : dst_pages; + d.src_pages = src->ttm->pages ? src->ttm->pages : src_pages; d.dst_num_pages =PFN_UP (dst->resource->size); d.src_num_pages =PFN_UP (src->resource->size); d.dst_prot =ttm_io_prot (dst, dst->resource,PAGE_KERNEL );
@@ -504,6 +529,10 @@ out:kunmap_atomic (d.src_addr);if (d.dst_addr)kunmap_atomic (d.dst_addr); +if (src_pages) +kvfree (src_pages); +if (dst_pages) +kvfree (dst_pages);return ret; }
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +4 -3
@@ -377,7 +377,8 @@ static int vmw_bo_init(struct vmw_privat {struct ttm_operation_ctx ctx = { .interruptible = params->bo_type != ttm_bo_type_kernel, - .no_wait_gpu = false + .no_wait_gpu = false, + .resv = params->resv, };struct ttm_device *bdev = &dev_priv->bdev;struct drm_device *vdev = &dev_priv->drm;
@@ -394,8 +395,8 @@ static int vmw_bo_init(struct vmw_privatvmw_bo_placement_set (vmw_bo, params->domain, params->busy_domain); ret =ttm_bo_init_reserved (bdev, &vmw_bo->tbo, params->bo_type, - &vmw_bo->placement,0 , &ctx,NULL , -NULL , destroy); + &vmw_bo->placement,0 , &ctx, + params->sg, params->resv, destroy);if (unlikely (ret))return ret;
drivers/gpu/drm/vmwgfx/vmwgfx_bo.h +2 -0
@@ -55,6 +55,8 @@ struct vmw_bo_params {enum ttm_bo_type bo_type;size_t size;bool pin; +struct dma_resv *resv; +struct sg_table *sg; };/**
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +1 -0
@@ -1628,6 +1628,7 @@ static const struct drm_driver driver = .prime_fd_to_handle = vmw_prime_fd_to_handle, .prime_handle_to_fd = vmw_prime_handle_to_fd, + .gem_prime_import_sg_table = vmw_prime_import_sg_table, .fops = &vmwgfx_driver_fops, .name = VMWGFX_DRIVER_NAME,
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +3 -0
@@ -1131,6 +1131,9 @@ extern int vmw_prime_handle_to_fd(structstruct drm_file *file_priv, uint32_t handle, uint32_t flags, int *prime_fd); +struct drm_gem_object *vmw_prime_import_sg_table (struct drm_device *dev, +struct dma_buf_attachment *attach, +struct sg_table *table);/* * MemoryOBject management - vmwgfx_mob.c
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c +32 -0
@@ -149,6 +149,38 @@ out_no_bo:return ret; } +struct drm_gem_object *vmw_prime_import_sg_table (struct drm_device *dev, +struct dma_buf_attachment *attach, +struct sg_table *table) +{ +int ret; +struct vmw_private *dev_priv =vmw_priv (dev); +struct drm_gem_object *gem =NULL ; +struct vmw_bo *vbo; +struct vmw_bo_params params = { + .domain = (dev_priv->has_mob) ?VMW_BO_DOMAIN_SYS :VMW_BO_DOMAIN_VRAM , + .busy_domain =VMW_BO_DOMAIN_SYS , + .bo_type = ttm_bo_type_sg, + .size = attach->dmabuf->size, + .pin = false, + .resv = attach->dmabuf->resv, + .sg = table, + + }; + +dma_resv_lock (params.resv,NULL ); + + ret =vmw_bo_create (dev_priv, ¶ms, &vbo); +if (ret !=0 ) + goto out_no_bo; + + vbo->tbo.base.funcs = &vmw_gem_object_funcs; + + gem = &vbo->tbo.base; +out_no_bo: +dma_resv_unlock (params.resv); +return gem; +}int vmw_gem_object_create_ioctl (struct drm_device *dev,void *data,struct drm_file *filp)
drivers/gpu/drm/vmwgfx/vmwgfx_prime.c +13 -2
@@ -75,8 +75,12 @@ int vmw_prime_fd_to_handle(struct drm_de int fd, u32 *handle) { struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile; +int ret =ttm_prime_fd_to_handle (tfile, fd, handle); -return ttm_prime_fd_to_handle (tfile, fd, handle); +if (ret) + ret =drm_gem_prime_fd_to_handle (dev, file_priv, fd, handle); + +return ret; } int vmw_prime_handle_to_fd(struct drm_device *dev,
@@ -85,5 +89,12 @@ int vmw_prime_handle_to_fd(struct drm_de int *prime_fd) {struct ttm_object_file *tfile =vmw_fpriv (file_priv)->tfile; -return ttm_prime_handle_to_fd (tfile, handle, flags, prime_fd); +int ret; + +if (handle >VMWGFX_NUM_MOB ) + ret =ttm_prime_handle_to_fd (tfile, handle, flags, prime_fd); +else + ret =drm_gem_prime_handle_to_fd (dev, file_priv, handle, flags, prime_fd); + +return ret; }
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c +30 -14
85 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 146/158 drm/vmwgfx: Sort primary plane formats by order of preference
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zack Rusin <[email protected]>
commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream.
The table of primary plane formats wasn't sorted at all, leading to applications picking our least desirable formats by defaults.
Sort the primary plane formats according to our order of preference.
Nice side-effect of this change is that it makes IGT's kms_atomic plane-invalid-params pass because the test picks the first format which for vmwgfx was DRM_FORMAT_XRGB1555 and uses fb's with odd sizes which make Pixman, which IGT depends on assert due to the fact that our 16bpp formats aren't 32 bit aligned like Pixman requires all formats to be.
--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h +2 -2
@@ -243,10 +243,10 @@ struct vmw_framebuffer_bo {static const uint32_t __maybe_unused vmw_primary_plane_formats[] = { -DRM_FORMAT_XRGB1555 , -DRM_FORMAT_RGB565 ,DRM_FORMAT_XRGB8888 ,DRM_FORMAT_ARGB8888 , +DRM_FORMAT_RGB565 , +DRM_FORMAT_XRGB1555 , };static const uint32_t __maybe_unused vmw_cursor_plane_formats[] = {
Greg Kroah-Hartman
maintainerPATCH 147/158 drm/vmwgfx: Fix crtcs atomic check conditional
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zack Rusin <[email protected]>
commit a60ccade88f926e871a57176e86a34bbf0db0098 upstream.
The conditional was supposed to prevent enabling of a crtc state without a set primary plane. Accidently it also prevented disabling crtc state with a set primary plane. Neither is correct.
Fix the conditional and just driver-warn when a crtc state has been enabled without a primary plane which will help debug broken userspace.
Fixes IGT's kms_atomic_interruptible and kms_atomic_transition tests.
--- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +8 -3
@@ -932,6 +932,7 @@ int vmw_du_cursor_plane_atomic_check(strint vmw_du_crtc_atomic_check (struct drm_crtc *crtc,struct drm_atomic_state *state) { +struct vmw_private *vmw =vmw_priv (crtc->dev);struct drm_crtc_state *new_state =drm_atomic_get_new_crtc_state (state, crtc);struct vmw_display_unit *du =vmw_crtc_to_du (new_state->crtc);
@@ -939,9 +940,13 @@ int vmw_du_crtc_atomic_check(struct drm_bool has_primary = new_state->plane_mask &drm_plane_mask (crtc->primary); -/* We always want to have an active plane with an active CRTC */ -if (has_primary != new_state->enable) -return -EINVAL ; +/* +* This is fine in general, but broken userspace might expect +* some actual rendering so give a clue as why it's blank. +*/ +if (new_state->enable && !has_primary) +drm_dbg_driver (&vmw->drm, +"CRTC without a primary plane will be blank.\n" ); if (new_state->connector_mask != connector_mask &&
Greg Kroah-Hartman
maintainerPATCH 148/158 nouveau: fix instmem race condition around ptr stores
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Airlie <[email protected]>
commit fff1386cc889d8fb4089d285f883f8cba62d82ce upstream.
Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:
...
? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]
Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm.
Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap.
If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read.
v2: use paired smp_rmb/smp_wmb.
--- drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c +6 -1
@@ -222,8 +222,11 @@ nv50_instobj_acquire(struct nvkm_memoryvoid __iomem *map =NULL ;/* Already mapped? */ -if (refcount_inc_not_zero (&iobj->maps)) +if (refcount_inc_not_zero (&iobj->maps)) { +/* read barrier match the wmb on refcount set */ +smp_rmb ();return iobj->map; + }/* Take the lock, and re-check that another thread hasn't * already mapped the object in the meantime.
@@ -250,6 +253,8 @@ nv50_instobj_acquire(struct nvkm_memory iobj->base.memory.ptrs = &nv50_instobj_fast; else iobj->base.memory.ptrs = &nv50_instobj_slow; +/* barrier to ensure the ptrs are written before refcount is set */ +smp_wmb ();refcount_set (&iobj->maps,1 ); }
Greg Kroah-Hartman
maintainerPATCH 149/158 bootconfig: use memblock_free_late to free xbc memory to buddy
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qiang Zhang <[email protected]>
commit 89f9a1e876b5a7ad884918c03a46831af202c8a0 upstream.
On the time to free xbc memory in xbc_exit(), memblock may has handed over memory to buddy allocator. So it doesn't make sense to free memory back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86. Following KASAN logs shows this case.
This patch fixes the xbc memory free problem by calling memblock_free() in early xbc init error rewind path and calling memblock_free_late() in xbc exit path to free memory to buddy allocator.
[ 9.410890] ================================================================== [ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260 [ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1
[ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5 [ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023 [ 9.460789] Call Trace: [ 9.463518] <TASK> [ 9.465859] dump_stack_lvl+0x53/0x70 [ 9.469949] print_report+0xce/0x610 [ 9.473944] ? __virt_addr_valid+0xf5/0x1b0 [ 9.478619] ? memblock_isolate_range+0x12d/0x260 [ 9.483877] kasan_report+0xc6/0x100 [ 9.487870] ? memblock_isolate_range+0x12d/0x260 [ 9.493125] memblock_isolate_range+0x12d/0x260 [ 9.498187] memblock_phys_free+0xb4/0x160 [ 9.502762] ? __pfx_memblock_phys_free+0x10/0x10 [ 9.508021] ? mutex_unlock+0x7e/0xd0 [ 9.512111] ? __pfx_mutex_unlock+0x10/0x10 [ 9.516786] ? kernel_init_freeable+0x2d4/0x430 [ 9.521850] ? __pfx_kernel_init+0x10/0x10 [ 9.526426] xbc_exit+0x17/0x70 [ 9.529935] kernel_init+0x38/0x1e0 [ 9.533829] ? _raw_spin_unlock_irq+0xd/0x30 [ 9.538601] ret_from_fork+0x2c/0x50 [ 9.542596] ? __pfx_kernel_init+0x10/0x10 [ 9.547170] ret_from_fork_asm+0x1a/0x30 [ 9.551552] </TASK>
[ 9.555649] The buggy address belongs to the physical page: [ 9.561875] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x45dd30 [ 9.570821] flags: 0x200000000000000(node=0|zone=2) [ 9.576271] page_type: 0xffffffff() [ 9.580167] raw: 0200000000000000 ffffea0011774c48 ffffea0012ba1848 0000000000000000 [ 9.588823] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 [ 9.597476] page dumped because: kasan: bad access detected
[ 9.605362] Memory state around the buggy address: [ 9.610714] ffff88845dd2ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.618786] ffff88845dd2ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.626857] >ffff88845dd30000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.634930] ^ [ 9.638534] ffff88845dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.654675] ==================================================================
--- include/linux/bootconfig.h | 7 ++++++- lib/bootconfig.c | 19 +++++++++++-------- 2 files changed, 17 insertions(+), 9 deletions(-)
include/linux/bootconfig.h +6 -1
@@ -288,7 +288,12 @@ int __init xbc_init(const char *buf, sizint __init xbc_get_info (int *node_size,size_t *data_size);/* XBC cleanup data structures */ -void __init xbc_exit (void ); +void __init _xbc_exit (bool early); + +static inline void xbc_exit (void ) +{ +_xbc_exit (false); +}/* XBC embedded bootconfig data in kernel */ #ifdef CONFIG_BOOT_CONFIG_EMBED
lib/bootconfig.c +11 -8
@@ -61,9 +61,12 @@ static inline void * __init xbc_alloc_me return memblock_alloc(size, SMP_CACHE_BYTES); } -static inline void __init xbc_free_mem (void *addr,size_t size) +static inline void __init xbc_free_mem (void *addr,size_t size,bool early) { -memblock_free (addr, size); +if (early) +memblock_free (addr, size); +else if (addr) +memblock_free_late (__pa (addr), size); }#else /* !__KERNEL__ */
@@ -73,7 +76,7 @@ static inline void *xbc_alloc_mem(size_treturn malloc (size); } -static inline void xbc_free_mem (void *addr,size_t size) +static inline void xbc_free_mem (void *addr,size_t size,bool early) {free (addr); }
@@ -904,13 +907,13 @@ static int __init xbc_parse_tree(void)* If you need to reuse xbc_init() with new boot config, you can * use this. */ -void __init xbc_exit (void ) +void __init _xbc_exit (bool early) { -xbc_free_mem (xbc_data, xbc_data_size); +xbc_free_mem (xbc_data, xbc_data_size, early); xbc_data =NULL ; xbc_data_size =0 ; xbc_node_num =0 ; -xbc_free_mem (xbc_nodes,sizeof (struct xbc_node ) *XBC_NODE_MAX ); +xbc_free_mem (xbc_nodes,sizeof (struct xbc_node ) *XBC_NODE_MAX , early); xbc_nodes =NULL ; brace_index =0 ; }
@@ -963,7 +966,7 @@ int __init xbc_init(const char *data, siif (!xbc_nodes) {if (emsg) *emsg ="Failed to allocate bootconfig nodes" ; -xbc_exit (); +_xbc_exit (true);return -ENOMEM ; }memset (xbc_nodes,0 ,sizeof (struct xbc_node ) *XBC_NODE_MAX );
@@ -977,7 +980,7 @@ int __init xbc_init(const char *data, si *epos = xbc_err_pos;if (emsg) *emsg = xbc_err_msg; -xbc_exit (); +_xbc_exit (true); }else ret = xbc_node_num;
Greg Kroah-Hartman
maintainerPATCH 150/158 Squashfs: check the inode number is not the invalid value of zero
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Phillip Lougher <[email protected]>
commit 9253c54e01b6505d348afbc02abaa4d9f8a01395 upstream.
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following sequence of events:
1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).
2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.
--- fs/squashfs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/squashfs/inode.c +4 -1
@@ -48,6 +48,10 @@ static int squashfs_new_inode(struct supgid_t i_gid;int err; + inode->i_ino =le32_to_cpu (sqsh_ino->inode_number); +if (inode->i_ino ==0 ) +return -EINVAL ; + err =squashfs_get_id (sb,le16_to_cpu (sqsh_ino->uid), &i_uid);if (err)return err;
@@ -58,7 +62,6 @@ static int squashfs_new_inode(struct supi_uid_write (inode, i_uid);i_gid_write (inode, i_gid); - inode->i_ino =le32_to_cpu (sqsh_ino->inode_number);inode_set_mtime (inode,le32_to_cpu (sqsh_ino->mtime),0 );inode_set_atime (inode,inode_get_mtime_sec (inode),0 );inode_set_ctime (inode,inode_get_mtime_sec (inode),0 );
Greg Kroah-Hartman
maintainerPATCH 151/158 nilfs2: fix OOB in nilfs_set_de_type
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeongjun Park <[email protected]>
commit c4a7dc9523b59b3e73fd522c73e95e072f876b16 upstream.
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT".
static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
*inode)
{
umode_t mode = inode->i_mode;
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
}However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.
--- fs/nilfs2/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nilfs2/dir.c +1 -1
@@ -240,7 +240,7 @@ nilfs_filetype_table[NILFS_FT_MAX] = {#define S_SHIFT 12static unsigned char -nilfs_type_by_mode[S_IFMT >>S_SHIFT ] = { +nilfs_type_by_mode[(S_IFMT >>S_SHIFT ) +1 ] = { [S_IFREG >>S_SHIFT ] =NILFS_FT_REG_FILE , [S_IFDIR >>S_SHIFT ] =NILFS_FT_DIR , [S_IFCHR >>S_SHIFT ] =NILFS_FT_CHRDEV ,
Greg Kroah-Hartman
maintainerPATCH 152/158 fork: defer linking file vma until vma is fully initialized
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaohe Lin <[email protected]>
commit 35e351780fa9d8240dd6f7e4f245f9ea37e96c19 upstream.
Thorvald reported a WARNING [1]. And the root cause is below race:
CPU 1 CPU 2
fork hugetlbfs_fallocate
dup_mmap hugetlbfs_punch_hole
i_mmap_lock_write(mapping);
vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. i_mmap_unlock_write(mapping);
hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem!
i_mmap_lock_write(mapping); hugetlb_vmdelete_list vma_interval_tree_foreach hugetlb_vma_trylock_write -- Vma_lock is cleared. tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! hugetlb_vma_unlock_write -- Vma_lock is assigned!!! i_mmap_unlock_write(mapping);
hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside i_mmap_rwsem lock while vma lock can be used in the same time. Fix this by deferring linking file vma until vma is fully initialized. Those vmas should be initialized first before they can be used.
--- kernel/fork.c | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-)
kernel/fork.c +17 -16
@@ -712,6 +712,23 @@ static __latent_entropy int dup_mmap(str }else if (anon_vma_fork (tmp, mpnt)) goto fail_nomem_anon_vma_fork;vm_flags_clear (tmp,VM_LOCKED_MASK ); +/* +* Copy/update hugetlb private vma information. +*/ +if (is_vm_hugetlb_page (tmp)) +hugetlb_dup_vma_private (tmp); + +/* +* Link the vma into the MT. After using __mt_dup(), memory +* allocation is not necessary here, so it cannot fail. +*/ +vma_iter_bulk_store (&vmi, tmp); + + mm->map_count++; + +if (tmp->vm_ops && tmp->vm_ops->open) + tmp->vm_ops->open (tmp); + file = tmp->vm_file;if (file) {struct address_space *mapping = file->f_mapping;
@@ -728,25 +745,9 @@ static __latent_entropy int dup_mmap(stri_mmap_unlock_write (mapping); } -/* -* Copy/update hugetlb private vma information. -*/ -if (is_vm_hugetlb_page (tmp)) -hugetlb_dup_vma_private (tmp); - -/* -* Link the vma into the MT. After using __mt_dup(), memory -* allocation is not necessary here, so it cannot fail. -*/ -vma_iter_bulk_store (&vmi, tmp); - - mm->map_count++;if (!(tmp->vm_flags &VM_WIPEONFORK )) retval =copy_page_range (tmp, mpnt); -if (tmp->vm_ops && tmp->vm_ops->open) - tmp->vm_ops->open (tmp); -if (retval) { mpnt =vma_next (&vmi); goto loop_out;
Greg Kroah-Hartman
maintainerPATCH 153/158 net: dsa: mt7530: fix improper frames on all 25MHz and 40MHz XTAL MT7530
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arınç ÜNAL <[email protected]>
commit 5f563c31ff0c40ce395d0bae7daa94c7950dac97 upstream.
The MT7530 switch after reset initialises with a core clock frequency that works with a 25MHz XTAL connected to it. For 40MHz XTAL, the core clock frequency must be set to 500MHz.
The mt7530_pll_setup() function is responsible of setting the core clock frequency. Currently, it runs on MT7530 with 25MHz and 40MHz XTAL. This causes MT7530 switch with 25MHz XTAL to egress and ingress frames improperly.
Introduce a check to run it only on MT7530 with 40MHz XTAL.
The core clock frequency is set by writing to a switch PHY's register. Access to the PHY's register is done via the MDIO bus the switch is also on. Therefore, it works only when the switch makes switch PHYs listen on the MDIO bus the switch is on. This is controlled either by the state of the ESW_P1_LED_1 pin after reset deassertion or modifying bit 5 of the modifiable trap register.
When ESW_P1_LED_1 is pulled high, PHY indirect access is used. That means accessing PHY registers via the PHY indirect access control register of the switch.
When ESW_P1_LED_1 is pulled low, PHY direct access is used. That means accessing PHY registers via the MDIO bus the switch is on.
For MT7530 switch with 40MHz XTAL on a board with ESW_P1_LED_1 pulled high, the core clock frequency won't be set to 500MHz, causing the switch to egress and ingress frames improperly.
Run mt7530_pll_setup() after PHY direct access is set on the modifiable trap register.
With these two changes, all MT7530 switches with 25MHz and 40MHz, and P1_LED_1 pulled high or low, will egress and ingress frames properly.
--- drivers/net/dsa/mt7530.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/dsa/mt7530.c +3 -2
@@ -2471,8 +2471,6 @@ mt7530_setup(struct dsa_switch *ds)SYS_CTRL_PHY_RST |SYS_CTRL_SW_RST | SYS_CTRL_REG_RST); -mt7530_pll_setup (priv); -/* Lower Tx driving for TRGMII path */ for (i =0 ; i <NUM_TRGMII_CTRL ; i++) mt7530_write(priv, MT7530_TRGMII_TD_ODT(i),
@@ -2490,6 +2488,9 @@ mt7530_setup(struct dsa_switch *ds) priv->p6_interface =PHY_INTERFACE_MODE_NA ; +if ((val &HWTRAP_XTAL_MASK ) ==HWTRAP_XTAL_40MHZ ) +mt7530_pll_setup (priv); +mt753x_trap_frames (priv);/* Enable and reset MIB counters */
Greg Kroah-Hartman
maintainerPATCH 154/158 net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arınç ÜNAL <[email protected]>
commit 06dfcd4098cfdc4d4577d94793a4f9125386da8b upstream.
The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features") brought EEE support but did not enable EEE on MT7531 switch MACs. EEE is enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board (bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to SkyLake Huang (黃啟澤) from MediaTek for providing information on the internal EEE switch bit.
There are existing boards that were not designed to pull the pin low. Because of that, the EEE status currently depends on the board design.
The EEE_DIS bit on the trap pertains to the LAN2LED0 pin which is usually used to control an LED. Once the bit is unset, the pin will be low. That will make the active low LED turn on. The pin is controlled by the switch PHY. It seems that the PHY controls the pin in the way that it inverts the pin state. That means depending on the wiring of the LED connected to LAN2LED0 on the board, the LED may be on without an active link.
To not cause this unwanted behaviour whilst enabling EEE on all boards, set the internal EEE switch bit on the CORE_PLL_GROUP4 register.
My testing on MT7531 shows a certain amount of traffic loss when EEE is enabled. That said, I haven't come across a board that enables EEE. So enable EEE on the switch MACs but disable EEE advertisement on the switch PHYs. This way, we don't change the behaviour of the majority of the boards that have this switch. The mediatek-ge PHY driver already disables EEE advertisement on the switch PHYs but my testing shows that it is somehow enabled afterwards. Disabling EEE advertisement before the PHY driver initialises keeps it off.
With this change, EEE can now be enabled using ethtool.
--- drivers/net/dsa/mt7530.c | 17 ++++++++++++----- drivers/net/dsa/mt7530.h | 1 + 2 files changed, 13 insertions(+), 5 deletions(-)
drivers/net/dsa/mt7530.c +12 -5
@@ -2712,18 +2712,25 @@ mt7531_setup(struct dsa_switch *ds) priv->p5_interface =PHY_INTERFACE_MODE_NA ; priv->p6_interface =PHY_INTERFACE_MODE_NA ; -/* Enable PHY core PLL, since phy_device has not yet been created -* provided for phy_[read,write]_mmd_indirect is called, we provide -* our own mt7531_ind_mmd_phy_[read,write] to complete this -* function. +/* Enable Energy-Efficient Ethernet (EEE) and PHY core PLL, since +* phy_device has not yet been created provided for +* phy_[read,write]_mmd_indirect is called, we provide our own +* mt7531_ind_mmd_phy_[read,write] to complete this function. */ val =mt7531_ind_c45_phy_read (priv,MT753X_CTRL_PHY_ADDR ,MDIO_MMD_VEND2 ,CORE_PLL_GROUP4 ); - val |=MT7531_PHY_PLL_BYPASS_MODE ; + val |=MT7531_RG_SYSPLL_DMY2 |MT7531_PHY_PLL_BYPASS_MODE ; val &= ~MT7531_PHY_PLL_OFF ;mt7531_ind_c45_phy_write (priv,MT753X_CTRL_PHY_ADDR ,MDIO_MMD_VEND2 ,CORE_PLL_GROUP4 , val); +/* Disable EEE advertisement on the switch PHYs. */ +for (i =MT753X_CTRL_PHY_ADDR ; + i <MT753X_CTRL_PHY_ADDR +MT7530_NUM_PHYS ; i++) { +mt7531_ind_c45_phy_write (priv, i,MDIO_MMD_AN ,MDIO_AN_EEE_ADV , +0 ); + } +mt7531_setup_common (ds);/* Setup VLAN ID 0 for VLAN-unaware bridges */
drivers/net/dsa/mt7530.h +1 -0
@@ -634,6 +634,7 @@ enum mt7531_clk_skew {#define RG_SYSPLL_DDSFBK_EN BIT(12)#define RG_SYSPLL_BIAS_EN BIT(11)#define RG_SYSPLL_BIAS_LPF_EN BIT(10) +#define MT7531_RG_SYSPLL_DMY2 BIT(6)#define MT7531_PHY_PLL_OFF BIT(5)#define MT7531_PHY_PLL_BYPASS_MODE BIT(4)
Greg Kroah-Hartman
maintainerPATCH 155/158 ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namjae Jeon <[email protected]>
commit c119f4ede3fa90a9463f50831761c28f989bfb20 upstream.
If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf().
--- fs/smb/server/server.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-)
fs/smb/server/server.c +5 -8
@@ -167,20 +167,17 @@ static void __handle_ksmbd_work(struct kint rc;bool is_chained = false; -if (conn->ops->allocate_rsp_buf (work)) -return ; -if (conn->ops->is_transform_hdr && conn->ops->is_transform_hdr (work->request_buf)) { rc = conn->ops->decrypt_req (work); -if (rc <0 ) { - conn->ops->set_rsp_status (work,STATUS_DATA_ERROR ); - goto send; - } - +if (rc <0 ) +return ; work->encrypted = true; } +if (conn->ops->allocate_rsp_buf (work)) +return ; + rc = conn->ops->init_rsp_hdr (work);if (rc) {/* either uid or tid is not correct */
Greg Kroah-Hartman
maintainerPATCH 156/158 ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namjae Jeon <[email protected]>
commit 17cf0c2794bdb6f39671265aa18aea5c22ee8c4a upstream.
The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.
--- fs/smb/server/smb2pdu.c | 4 ++++ 1 file changed, 4 insertions(+)
fs/smb/server/smb2pdu.c +4 -0
@@ -535,6 +535,10 @@ int smb2_allocate_rsp_buf(struct ksmbd_wif (cmd ==SMB2_QUERY_INFO_HE ) {struct smb2_query_info_req *req; +if (get_rfc1002_len (work->request_buf) < + offsetof(struct smb2_query_info_req , OutputBufferLength)) +return -EINVAL ; + req =smb2_get_msg (work->request_buf); if ((req->InfoType == SMB2_O_INFO_FILE && (req->FileInfoClass == FILE_FULL_EA_INFORMATION ||
Greg Kroah-Hartman
maintainerPATCH 157/158 ksmbd: clear RENAME_NOREPLACE before calling vfs_rename
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marios Makassikis <[email protected]>
commit 4973b04d3ea577db80c501c5f14e68ec69fe1794 upstream.
File overwrite case is explicitly handled, so it is not necessary to pass RENAME_NOREPLACE to vfs_rename.
Clearing the flag fixes rename operations when the share is a ntfs-3g mount. The latter uses an older version of fuse with no support for flags in the ->rename op.
--- fs/smb/server/vfs.c | 5 +++++ 1 file changed, 5 insertions(+)
fs/smb/server/vfs.c +5 -0
@@ -754,10 +754,15 @@ retry: goto out4; } +/* +* explicitly handle file overwrite case, for compatibility with +* filesystems that may not support rename flags (e.g: fuse) +*/ if ((flags &RENAME_NOREPLACE ) &&d_is_positive (new_dentry)) { err = -EEXIST ; goto out4; } + flags &= ~(RENAME_NOREPLACE );if (old_child == trap) { err = -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 158/158 ksmbd: common: use struct_group_attr instead of struct_group for network_open_info
In reply to Greg Kroah-Hartman6.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namjae Jeon <[email protected]>
commit 0268a7cc7fdc47d90b6c18859de7718d5059f6f1 upstream.
4byte padding cause the connection issue with the applications of MacOS. smb2_close response size increases by 4 bytes by padding, And the smb client of MacOS check it and stop the connection. This patch use struct_group_attr instead of struct_group for network_open_info to use
__packed to avoid padding.
--- fs/smb/common/smb2pdu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/smb/common/smb2pdu.h +1 -1
@@ -702,7 +702,7 @@ struct smb2_close_rsp {__le16 StructureSize;/* 60 */ __le16 Flags;__le32 Reserved; - struct_group(network_open_info, + struct_group_attr(network_open_info, __packed, __le64 CreationTime; __le64 LastAccessTime; __le64 LastWriteTime;
Hello,
Quoted 5 lines · On Tue, 23 Apr 2024 14:37:02 -0700 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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.
Quoted 8 lines
Responses should be made by Thu, 25 Apr 2024 21:38:28 +0000. 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/v6.x/stable-review/patch-6.8.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.8.y
and the diffstat can be found below.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 9919cd9ab988 ("Linux 6.8.8-rc1")
Thanks,
SJ
[...]
---
ok 2 selftests: damon: debugfs_schemes.sh
ok 3 selftests: damon: debugfs_target_ids.sh
ok 4 selftests: damon: debugfs_empty_targets.sh
ok 5 selftests: damon: debugfs_huge_count_read_write.sh
ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: debugfs_rm_non_contexts.sh
ok 8 selftests: damon: sysfs.sh
ok 9 selftests: damon: sysfs_update_removed_scheme_dir.sh
ok 10 selftests: damon: sysfs_update_schemes_tried_regions_hang.py ok 11 selftests: damon: sysfs_update_schemes_tried_regions_wss_estimation.py ok 12 selftests: damon: reclaim.sh
ok 13 selftests: damon: lru_sort.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh
ok 12 selftests: damon-tests: build_m68k.sh
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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.
Successfully compiled and installed the kernel on my computer (Acer Aspire E15, Intel Core i3 Haswell). No noticeable regressions.
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.8.y
6.6.x compiles ok, too.
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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 Thu, 25 Apr 2024 21:38:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.8.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.8.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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 Thu, 25 Apr 2024 21:38:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.8.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.8.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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 Thu, 25 Apr 2024 21:38:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.8.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.8.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, x86_64, and i386.
One regression on arm,
the TI BeagleBoard-X15 device kunit test boot failed and it is always reproducible.
Not a problem on qemu-armv7.
However, I am bisecting this problem and let you know shortly.
Links:
---
- https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2fWFwczHZDFUGnjqyT1mZ6wIeS9
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.8.y/build/v6.8.7-159-g9919cd9ab988/testrun/23660959/suite/boot/test/gcc-13-lkftconfig-kunit/details/
log:
Signature · 83 lines
[ 45.931457] BUG: KASAN: slab-out-of-bounds in krealloc_more_oob_helper+0x464/0x4c0 [ 45.950073] Write of size 1 at addr cacc68eb by task kunit_try_catch/176 [ 45.956817] [ 45.958312] CPU: 0 PID: 176 Comm: kunit_try_catch Tainted: G B W N 6.8.8-rc1 #1 [ 45.966735] Hardware name: Generic DRA74X (Flattened Device Tree) [ 45.972869] unwind_backtrace from show_stack+0x18/0x1c [ 45.978149] show_stack from dump_stack_lvl+0x6c/0x8c [ 45.983245] dump_stack_lvl from print_report+0x158/0x510 [ 45.988677] print_report from kasan_report+0xc8/0x104 [ 45.993865] kasan_report from krealloc_more_oob_helper+0x464/0x4c0 [ 46.000183] krealloc_more_oob_helper from kunit_try_run_case+0x224/0x598 [ 46.007019] kunit_try_run_case from kunit_generic_run_threadfn_adapter+0x84/0xe4 [ 46.014556] kunit_generic_run_threadfn_adapter from kthread+0x378/0x410 [ 46.021331] kthread from ret_from_fork+0x14/0x28 [ 46.026062] Exception stack(0xf219bfb0 to 0xf219bff8) [ 46.031158] bfa0: 00000000 00000000 00000000 00000000 [ 46.039367] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 46.047607] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 46.054260] [ 46.055755] Allocated by task 176: [ 46.059173] kasan_save_track+0x30/0x5c [ 46.063049] __kasan_krealloc+0xf0/0x13c [ 46.067016] krealloc+0xb8/0xfc [ 46.070190] krealloc_more_oob_helper+0xd4/0x4c0 [ 46.074829] kunit_try_run_case+0x224/0x598 [ 46.079040] kunit_generic_run_threadfn_adapter+0x84/0xe4 [ 46.084472] kthread+0x378/0x410 [ 46.087738] ret_from_fork+0x14/0x28 [ 46.091339] [ 46.092834] The buggy address belongs to the object at cacc6800 [ 46.092834] which belongs to the cache kmalloc-256 of size 256 [ 46.104736] The buggy address is located 0 bytes to the right of [ 46.104736] allocated 235-byte region [cacc6800, cacc68eb) [ 46.116363] [ 46.117858] The buggy address belongs to the physical page: [ 46.123474] page:af853d8a refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x8acc6 [ 46.131439] head:af853d8a order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 46.138885] flags: 0x840(slab|head|zone=0) [ 46.143005] page_type: 0xffffffff() [ 46.146514] raw: 00000840 c6801500 00000122 00000000 00000000 80100010 ffffffff 00000001 [ 46.154663] raw: 00000000 [ 46.157287] page dumped because: kasan: bad access detected [ 46.162902] [ 46.164398] Memory state around the buggy address: [ 46.169219] cacc6780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 46.175781] cacc6800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 46.182373] >cacc6880: 00 00 00 00 00 00 00 00 00 00 00 00 00 03 fc fc [ 46.188934] ^ [ 46.194885] cacc6900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 46.201446] cacc6980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 46.208038] ================================================================== [ 46.215454] hub 1-1:1.0: 4 ports detected [ 46.215637] ================================================================== [ 46.226745] BUG: KASAN: slab-out-of-bounds in krealloc_more_oob_helper+0x458/0x4c0 [ 46.234374] Write of size 1 at addr cacc68f0 by task kunit_try_catch/176 <common> [ 46.570037] krealloc_less_oob_helper from kunit_try_run_case+0x224/0x598 <common> [ 46.576873] kunit_try_run_case from kunit_generic_run_threadfn_adapter+0x84/0xe4 <common> [ 46.584411] kunit_generic_run_threadfn_adapter from kthread+0x378/0x410 ## Build * kernel: 6.8.8-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-6.8.y * git commit: ea4e35f1afd7d7d003c345bf14862183910ecc6b * git describe: v6.8.7-159-gea4e35f1afd7 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.8.y/build/v6.8.7-159-gea4e35f1afd7 -- Linaro LKFT https://lkft.linaro.org
Naresh Kamboju
Tested-by Linux Kernel Functional TestingQuoted 26 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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 Thu, 25 Apr 2024 21:38:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.8.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.8.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64,x86_64, and i386.
Quoted 7 lines
One regression on arm,
the TI BeagleBoard-X15 device kunit test boot failed and it is always reproducible.Not a problem on qemu-armv7.
However, I am bisecting this problem and let you know shortly.
After investigation it is found that it is an intermittent issue where log-in prompt was not successful intermittently and results showed a boot failed but it is not.
However, This is not regression.
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.8.8-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.8.y
* git commit: 9919cd9ab98868581abf895dc0913cb6760c176f
* git describe: v6.8.7-159-g9919cd9ab988
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.8.y/build/v6.8.7-159-g9919cd9ab988
## Test Regressions (compared to v6.8.7)
## Metric Regressions (compared to v6.8.7)
## Test Fixes (compared to v6.8.7)
## Metric Fixes (compared to v6.8.7)
## Test result summary
total: 183677, pass: 159323, fail: 2769, skip: 21350, xfail: 235
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 128 total, 128 passed, 0 failed
* arm64: 38 total, 38 passed, 0 failed
* i386: 29 total, 29 passed, 0 failed
* mips: 23 total, 23 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 34 total, 34 passed, 0 failed
* riscv: 17 total, 17 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 33 total, 33 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mm
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-smoketest
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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 Thu, 25 Apr 2024 21:38:28 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.8.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.8.y
and the diffstat can be found below.thanks,
greg k-h
No new regressions for Tegra ...
Test results for stable-v6.8:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
106 tests: 105 pass, 1 failLinux version: 6.8.8-rc1-g9919cd9ab988
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Test failures: tegra194-p2972-0000: boot.py
Jon
Signature · 1 line
nvpublic
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.8.8 release. There are 158 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.
Quoted 9 lines
Responses should be made by Thu, 25 Apr 2024 21:38:28 +0000. 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/v6.x/stable-review/patch-6.8.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.8.y
and the diffstat can be found below.
KernelCI report for stable-rc/linux-6.8.y for this week :-
## stable-rc HEAD for linux-6.8.y:
Date: 2024-04-24
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=9919cd9ab98868581abf895dc0913cb6760c176f
## Build failures:
No build failures seen for the stable-rc/linux-6.8.y commit head \o/
## Boot failures:
No **new** boot failures seen for the stable-rc/linux-6.8.y commit head \o/
Thanks,
Shreeya Patel