search for: map_size

Attached is a patch that makes window strides constant when files are walked with a constant block size. In these cases, it completely avoids all memmoves. In my simple local test of rsyncing 57MB of 10 local files, memmoved bytes went from 18MB to zero. I haven't tested this for a big variety of file cases. I think that this will always reduce the memmoves involved with walking a large

...ething which needs action? If not, I'll start ignoring them. Nov 11 19:00:45 tm samba-dcerpcd[7373]: [2024/11/11 19:00:45.852391, 0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log) Nov 11 19:00:45 tm samba-dcerpcd[7373]: tdb(/var/db/samba4/gencache.tdb): tdb_expand overflow detected current map_size[4294967295] size[128]! Nov 11 19:00:45 tm samba-dcerpcd[7373]: [2024/11/11 19:00:45.853054, 0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log) Nov 11 19:00:45 tm samba-dcerpcd[7373]: tdb(/var/db/samba4/gencache.tdb): tdb_expand overflow detected current map_size[4294967295] size[128]! Nov 11 22:1...

...log entries over a one hour period (about 95 messages per second). > > Nov 18 12:00:00 tm smbd[70983]: [2024/11/18 12:00:00.027823, 0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log) > Nov 18 12:00:00 tm smbd[70983]: tdb(/var/db/samba4/gencache.tdb): tdb_expand overflow detected current map_size[4294967295] size[128]! Is the file system size of /var/db/samba4/gencache.tdb also 4294967295? I think something outside of tdb must be causing this to go haywire. What are the last messages before this starts happening? Douglas

...over a one hour period (about 95 messages per second). >> >> Nov 18 12:00:00 tm smbd[70983]: [2024/11/18 12:00:00.027823, 0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log) >> Nov 18 12:00:00 tm smbd[70983]: tdb(/var/db/samba4/gencache.tdb): tdb_expand overflow detected current map_size[4294967295] size[128]! > > Is the file system size of /var/db/samba4/gencache.tdb also 4294967295? The latest message is: Nov 19 22:45:31 tm smbd[9742]: [2024/11/19 22:45:31.622727, 0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log) Nov 19 22:45:31 tm smbd[9742]: tdb(/var/db/samba4/gencac...

...ot, I'll start ignoring them. > > Nov 11 19:00:45 tm samba-dcerpcd[7373]: [2024/11/11 19:00:45.852391, > 0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log) > Nov 11 19:00:45 tm samba-dcerpcd[7373]: > tdb(/var/db/samba4/gencache.tdb): tdb_expand overflow detected current > map_size[4294967295] size[128]! > Nov 11 19:00:45 tm samba-dcerpcd[7373]: [2024/11/11 19:00:45.853054, > 0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log) > Nov 11 19:00:45 tm samba-dcerpcd[7373]: > tdb(/var/db/samba4/gencache.tdb): tdb_expand overflow detected current > map_size[429496...

...or: tdb_recovery_allocate: overflow recovery area tdb_transaction_prepare_commit: failed to setup recovery data ../lib/tdb/common/tdb.c:1055 Failed to commit I follow the code and found this line: transaction.c:783         /* New head will be at end of file. */         recovery_head = tdb->map_size; In my case it means following: my filesize is 3,3GB, old recovery_head was on 2064351232, size of old recovery was about 923820008, size of new recovery should be 1323794228, after tdb_free of old recovery area and setting the new recovery head to end of file(tdb->map_size), it is no more...

...tdown(uint32_t shutdown_type) @@ -59,16 +60,8 @@ void tboot_shutdown(uint32_t shutdown_ty local_irq_disable(); /* Create identity map for tboot shutdown code. */ - if ( g_tboot_shared->version >= 0x02 ) - { - map_base = PFN_DOWN(g_tboot_shared->tboot_base); - map_size = PFN_UP(g_tboot_shared->tboot_size); - } - else - { - map_base = 0; - map_size = PFN_UP(0xa0000); - } + map_base = PFN_DOWN(g_tboot_shared->tboot_base); + map_size = PFN_UP(g_tboot_shared->tboot_size); err = map_pages_to_xen(map_base << PAGE_SHI...

...NIT_LIST_HEAD(&msi_page->list); diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index de91dd88705bd3..fe29fc2140b132 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -930,7 +930,7 @@ static int iommu_create_device_direct_mappings(struct iommu_group *group, if (map_size) { ret = iommu_map(domain, addr - map_size, addr - map_size, map_size, - entry->prot); + entry->prot, GFP_KERNEL); if (ret) goto out; map_size = 0; @@ -2360,31 +2360,26 @@ static int __iommu_map(struct iommu_domain *domain, unsigned long iova, return re...

...NIT_LIST_HEAD(&msi_page->list); diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index de91dd88705bd3..fe29fc2140b132 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -930,7 +930,7 @@ static int iommu_create_device_direct_mappings(struct iommu_group *group, if (map_size) { ret = iommu_map(domain, addr - map_size, addr - map_size, map_size, - entry->prot); + entry->prot, GFP_KERNEL); if (ret) goto out; map_size = 0; @@ -2360,31 +2360,26 @@ static int __iommu_map(struct iommu_domain *domain, unsigned long iova, return re...

...NIT_LIST_HEAD(&msi_page->list); diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index de91dd88705bd3..fe29fc2140b132 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -930,7 +930,7 @@ static int iommu_create_device_direct_mappings(struct iommu_group *group, if (map_size) { ret = iommu_map(domain, addr - map_size, addr - map_size, map_size, - entry->prot); + entry->prot, GFP_KERNEL); if (ret) goto out; map_size = 0; @@ -2360,31 +2360,26 @@ static int __iommu_map(struct iommu_domain *domain, unsigned long iova, return re...

...area > tdb_transaction_prepare_commit: failed to setup recovery data > ../lib/tdb/common/tdb.c:1055 Failed to commit > > I follow the code and found this line: > > transaction.c:783 > > /* New head will be at end of file. */ > recovery_head = tdb->map_size; > > In my case it means following: > > my filesize is 3,3GB, old recovery_head was on 2064351232, size of old > recovery was about 923820008, size of new recovery should be 1323794228, > after tdb_free of old recovery area and setting the new recovery head to > end of fil...

...source3/lib/util_tdb.c:313(tdb_log) tdb(<PATH OMMITTED>/gencache_notrans.tdb): tdb_rec_read bad magic 0xd9fee666 at offset=517632 [2015/10/16 10:25:37.827964, 0] ../source3/lib/util_tdb.c:313(tdb_log) tdb(<PATH OMMITTED>/gencache_notrans.tdb): tdb_expand overflow detected current map_size[4294967295] size[124]! """ These messages appear in *great* number, especially the message about "tdb_expand overflow detected." Interestingly, the size of the file it mentions is the exact size in bytes as the presumed array reference index that the error message lists...

...ions(+), 13 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index a4790bf..bd78773 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -157,50 +157,48 @@ static unsigned long __init xen_populate_chunk( unsigned long dest_pfn; for (i = 0, entry = list; i < map_size; i++, entry++) { - unsigned long credits = credits_left; unsigned long s_pfn; unsigned long e_pfn; unsigned long pfns; long capacity; - if (credits <= 0) + if (credits_left <= 0) break; if (entry->type != E820_RAM) continue; - e_pfn = PFN_UP(entry->addr...

...ions(+), 13 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index a4790bf..bd78773 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -157,50 +157,48 @@ static unsigned long __init xen_populate_chunk( unsigned long dest_pfn; for (i = 0, entry = list; i < map_size; i++, entry++) { - unsigned long credits = credits_left; unsigned long s_pfn; unsigned long e_pfn; unsigned long pfns; long capacity; - if (credits <= 0) + if (credits_left <= 0) break; if (entry->type != E820_RAM) continue; - e_pfn = PFN_UP(entry->addr...

Rowland, I commented out what you asked me to, no change. # Global parameters [global] workgroup = TRUEVINE realm = TRUEVINE.LAN netbios name = DC01 server role = active directory domain controller server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbi$ # idmap_ldb:use rfc2307 = yes # idmap config *:backend = tdb # idmap

...ot Info Arch (XBIA) memory map structure. */ typedef struct { /* * Amount of lower memory accordingly to The Multiboot * Specification version 0.6.96. */ u32 lower; /* * Amount of upper memory accordingly to The Multiboot * Specification version 0.6.96. */ u32 upper; u32 map_size; struct e820entry *e820map; } xbia_mem_t; /* Xen Boot Info Arch (XBIA). */ typedef struct { EFI_SYSTEM_TABLE *efi_system_table; u64 mps; /* Pointer to MPS. */ u64 acpi; /* Pointer to ACPI RSDP. */ u64 smbios; /* Pointer to SMBIOS. */ xbia_mem_t mem; struct xen_vga_console_info vga_co...

...it a/hw/pt-graphics.c b/hw/pt-graphics.c index c6f8869..3f2b285 100644 --- a/hw/pt-graphics.c +++ b/hw/pt-graphics.c @@ -81,6 +81,7 @@ uint32_t igd_read_opregion(struct pt_dev *pci_dev) void igd_write_opregion(struct pt_dev *real_dev, uint32_t val) { uint32_t host_opregion = 0; + uint32_t map_size = 2; int ret; if ( igd_guest_opregion ) @@ -74,11 +93,13 @@ void igd_write_opregion(struct pt_dev *real_dev, uint32_t val) host_opregion = pt_pci_host_read(real_dev->pci_dev, PCI_INTEL_OPREGION, 4); igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);...

This patch series introduces the VHD library. It is based on the blktap2 one, with changes coming from the blktap2.5 one. Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>

...3(tdb_log) > tdb(<PATH OMMITTED>/gencache_notrans.tdb): tdb_rec_read bad magic 0xd9fee666 at offset=517632 > > > [2015/10/16 10:25:37.827964, 0] ../source3/lib/util_tdb.c:313(tdb_log) > tdb(<PATH OMMITTED>/gencache_notrans.tdb): tdb_expand overflow detected current map_size[4294967295] size[124]! tdb_rec_read bad magic - this means a corrupted tdb database. Can you shutdown, remove these tdb's and restart ?

iommufd follows the same design as KVM and uses memory cgroups to limit the amount of kernel memory a iommufd file descriptor can pin down. The various internal data structures already use GFP_KERNEL_ACCOUNT to charge its own memory. However, one of the biggest consumers of kernel memory is the IOPTEs stored under the iommu_domain and these allocations are not tracked. This series is the first