lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Sep 2017 20:40:05 +0530 From: Shivasharan Srikanteshwara <shivasharan.srikanteshwara@...adcom.com> To: Christoph Hellwig <hch@...radead.org>, shuwang@...hat.com Cc: Kashyap Desai <kashyap.desai@...adcom.com>, Sumit Saxena <sumit.saxena@...adcom.com>, jejb@...ux.vnet.ibm.com, martin.petersen@...cle.com, "PDL,MEGARAIDLINUX" <megaraidlinux.pdl@...adcom.com>, linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org, chuhu@...hat.com, yizhan@...hat.com, catalin.marinas@....com Subject: RE: [PATCH V2] megaraid: kmemleak: Track page allocation for fusion > -----Original Message----- > From: Christoph Hellwig [mailto:hch@...radead.org] > Sent: Friday, September 15, 2017 11:30 PM > To: shuwang@...hat.com > Cc: kashyap.desai@...adcom.com; sumit.saxena@...adcom.com; > shivasharan.srikanteshwara@...adcom.com; jejb@...ux.vnet.ibm.com; > martin.petersen@...cle.com; megaraidlinux.pdl@...adcom.com; linux- > scsi@...r.kernel.org; linux-kernel@...r.kernel.org; chuhu@...hat.com; > yizhan@...hat.com; catalin.marinas@....com > Subject: Re: [PATCH V2] megaraid: kmemleak: Track page allocation for fusion > > I think the megaraid fusion code has a deeper problem here. > > Instead of playing weird games with get_free_pages and vmalloc the structure > just needs to shrink by moving all the arrays of MAX_MSIX_QUEUES_FUSION > size into a separate allocation for each, and then we have normall, small > kmalloc allocations. Hi Christoph, We understand your suggestion on shrinking the size of fusion_context so that we can use kmalloc to allocate the structure. Size of fusion_context structure now is about 179kB and it is contributed almost entirely by log_to_span array (~176kB). The rest of the arrays do not make as much difference to the size. We will send a new patch that separates allocation for log_to_span array from fusion_context. For now it is a Nack for this patch then. crash> struct -o fusion_context struct fusion_context { [0] struct megasas_cmd_fusion **cmd_list; [8] dma_addr_t req_frames_desc_phys; [16] u8 *req_frames_desc; [24] struct dma_pool *io_request_frames_pool; [32] dma_addr_t io_request_frames_phys; [40] u8 *io_request_frames; [48] struct dma_pool *sg_dma_pool; [56] struct dma_pool *sense_dma_pool; [64] dma_addr_t reply_frames_desc_phys[128]; [1088] union MPI2_REPLY_DESCRIPTORS_UNION *reply_frames_desc[128]; [2112] struct dma_pool *reply_frames_desc_pool; [2120] u16 last_reply_idx[128]; [2376] u32 reply_q_depth; [2380] u32 request_alloc_sz; [2384] u32 reply_alloc_sz; [2388] u32 io_frames_alloc_sz; [2392] struct MPI2_IOC_INIT_RDPQ_ARRAY_ENTRY *rdpq_virt; [2400] dma_addr_t rdpq_phys; [2408] u16 max_sge_in_main_msg; [2410] u16 max_sge_in_chain; [2412] u8 chain_offset_io_request; [2413] u8 chain_offset_mfi_pthru; [2416] struct MR_FW_RAID_MAP_DYNAMIC *ld_map[2]; [2432] dma_addr_t ld_map_phys[2]; [2448] struct MR_DRV_RAID_MAP_ALL *ld_drv_map[2]; [2464] u32 max_map_sz; [2468] u32 current_map_sz; [2472] u32 old_map_sz; [2476] u32 new_map_sz; [2480] u32 drv_map_sz; [2484] u32 drv_map_pages; [2488] struct MR_PD_CFG_SEQ_NUM_SYNC *pd_seq_sync[2]; [2504] dma_addr_t pd_seq_phys[2]; [2520] u8 fast_path_io; [2528] struct LD_LOAD_BALANCE_INFO *load_balance_info; [2536] u32 load_balance_info_pages; [2544] LD_SPAN_INFO log_to_span[256]; [182768] u8 adapter_type; [182776] struct LD_STREAM_DETECT **stream_detect_by_ld; } SIZE: 182784 Thanks, Shivasharan
Powered by blists - more mailing lists