Re: [Savannah-users] Anonymous commit (empty Author and Committer)
> 30.10.2015 23:59, Lennart Sorensen пишет: > >> On Fri, Oct 30, 2015 at 09:19:19PM +0100, Vladimir 'φ-coder/phcoder' >> Serbinenko wrote: >> >>> On 30.10.2015 21:09, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>> On 30.10.2015 21:06, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 30.10.2015 15:26, Andrei Borzenkov wrote: > >> See >> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac >> >> I was not even aware that this is possible. Is there anything on server >> side that can prevent it? >> >> Would be good if commit were amended and force pushed to fix it. > > It is a bug in SGit. I'll investigate how it happened >>> >>> I don't have non-fast-forward rights. Does someone from savannah-users >>> have them? Could he just delete this commit? >> >> If you do that, then anyone that already did a pull after it went in >> will have a broken tree. Rather annoying. > > If we decide to fix this commit it is better done now, while it is the > last one. It is annoying but do you have suggestion how it can be done > differently? +1 to undo it now Indeed. The faster it is fixed smaller the number of potential unintentional repeats for it, if any. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Anonymous commit (empty Author and Committer)
30.10.2015 23:19, Vladimir 'φ-coder/phcoder' Serbinenko пишет: On 30.10.2015 21:09, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 30.10.2015 21:06, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 30.10.2015 15:26, Andrei Borzenkov wrote: See http://git.savannah.gnu.org/cgit/grub.git/commit/?id=206676601eb853fc319df14cd3398fbdfde665ac I was not even aware that this is possible. Is there anything on server side that can prevent it? Would be good if commit were amended and force pushed to fix it. It is a bug in SGit. I'll investigate how it happened I don't have non-fast-forward rights. Does someone from savannah-users have them? Could he just delete this commit? Looking at mail archives, non-fast-forward is global repository property and disabled by default. We probably need to open Savannah ticket to get it temporary enabled. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Savannah-users] Anonymous commit (empty Author and Committer)
31.10.2015 10:02, Andreas Schwab пишет: Kaz Kylheku writes: Nope. They will have a git in which that commit looks like their own local work. *Someone* will inadvertently do a "git push" to blast out their changes based on that deleted commit, thereby causing it to reappear. Not if another one pushes something different in the mean time. Which is why I said "amended". ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Savannah-users] Anonymous commit (empty Author and Committer)
Kaz Kylheku writes: > Nope. They will have a git in which that commit looks like their own > local work. *Someone* will inadvertently do a "git push" to blast out > their changes based on that deleted commit, thereby causing it to > reappear. Not if another one pushes something different in the mean time. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Savannah-users] Anonymous commit (empty Author and Committer)
On 30.10.2015 13:59, Lennart Sorensen wrote: I don't have non-fast-forward rights. Does someone from savannah-users have them? Could he just delete this commit? If you do that, then anyone that already did a pull after it went in will have a broken tree. Rather annoying. Nope. They will have a git in which that commit looks like their own local work. *Someone* will inadvertently do a "git push" to blast out their changes based on that deleted commit, thereby causing it to reappear. :) ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH V2] mkimage: zero fill alignment space
This did not cause real problem but is good for reproducible builds. I hit
it with recent bootinfoscript that displays embedded config; I was puzzled
by random garbage at the end.
Prezero memory buffer used to assemble core.img. This makes individual
memset redundant. Also ensure buffer is filled with zeroes in several other
places.
Also remove redundant zeroing code where we fill in the whole memory block
anyway.
---
util/grub-mkimagexx.c | 3 ++-
util/mkimage.c| 30 +-
2 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
index 3c76d07..a1ddc62 100644
--- a/util/grub-mkimagexx.c
+++ b/util/grub-mkimagexx.c
@@ -101,7 +101,7 @@ SUFFIX (generate_elf) (const struct
grub_install_image_target_desc *image_target
program_size = ALIGN_ADDR (*core_size);
elf_img = xmalloc (program_size + header_size + footer_size);
- memset (elf_img, 0, program_size + header_size);
+ memset (elf_img, 0, program_size + header_size + footer_size);
memcpy (elf_img + header_size, *core_img, *core_size);
ehdr = (void *) elf_img;
phdr = (void *) (elf_img + sizeof (*ehdr));
@@ -1587,6 +1587,7 @@ SUFFIX (load_image) (const char *kernel_path, size_t
*exec_size,
}
out_img = xmalloc (*kernel_sz + total_module_size);
+ memset (out_img, 0, *kernel_sz + total_module_size);
if (image_target->id == IMAGE_EFI)
{
diff --git a/util/mkimage.c b/util/mkimage.c
index 35df998..dc40461 100644
--- a/util/mkimage.c
+++ b/util/mkimage.c
@@ -992,7 +992,7 @@ grub_install_generate_image (const char *dir, const char
*prefix,
{
char *kernel_img, *core_img;
size_t kernel_size, total_module_size, core_size, exec_size;
- size_t memdisk_size = 0, config_size = 0, config_size_pure = 0;
+ size_t memdisk_size = 0, config_size = 0;
size_t prefix_size = 0;
char *kernel_path;
size_t offset;
@@ -1043,8 +1043,7 @@ grub_install_generate_image (const char *dir, const char
*prefix,
if (config_path)
{
- config_size_pure = grub_util_get_image_size (config_path) + 1;
- config_size = ALIGN_ADDR (config_size_pure);
+ config_size = ALIGN_ADDR (grub_util_get_image_size (config_path) + 1);
grub_util_info ("the size of config file is 0x%" GRUB_HOST_PRIxLONG_LONG,
(unsigned long long) config_size);
total_module_size += config_size + sizeof (struct grub_module_header);
@@ -1080,7 +1079,10 @@ grub_install_generate_image (const char *dir, const char
*prefix,
= grub_host_to_target32 (total_module_size);
if (image_target->flags & PLATFORM_FLAGS_MODULES_BEFORE_KERNEL)
-memmove (kernel_img + total_module_size, kernel_img, kernel_size);
+{
+ memmove (kernel_img + total_module_size, kernel_img, kernel_size);
+ memset (kernel_img, 0, total_module_size);
+}
if (image_target->voidp_sizeof == 8)
{
@@ -1090,7 +1092,6 @@ grub_install_generate_image (const char *dir, const char
*prefix,
modinfo = (struct grub_module_info64 *) kernel_img;
else
modinfo = (struct grub_module_info64 *) (kernel_img + kernel_size);
- memset (modinfo, 0, sizeof (struct grub_module_info64));
modinfo->magic = grub_host_to_target32 (GRUB_MODULE_MAGIC);
modinfo->offset = grub_host_to_target_addr (sizeof (struct
grub_module_info64));
modinfo->size = grub_host_to_target_addr (total_module_size);
@@ -1107,7 +1108,6 @@ grub_install_generate_image (const char *dir, const char
*prefix,
modinfo = (struct grub_module_info32 *) kernel_img;
else
modinfo = (struct grub_module_info32 *) (kernel_img + kernel_size);
- memset (modinfo, 0, sizeof (struct grub_module_info32));
modinfo->magic = grub_host_to_target32 (GRUB_MODULE_MAGIC);
modinfo->offset = grub_host_to_target_addr (sizeof (struct
grub_module_info32));
modinfo->size = grub_host_to_target_addr (total_module_size);
@@ -1120,17 +1120,14 @@ grub_install_generate_image (const char *dir, const
char *prefix,
for (p = path_list; p; p = p->next)
{
struct grub_module_header *header;
- size_t mod_size, orig_size;
+ size_t mod_size;
- orig_size = grub_util_get_image_size (p->name);
- mod_size = ALIGN_ADDR (orig_size);
+ mod_size = ALIGN_ADDR (grub_util_get_image_size (p->name));
header = (struct grub_module_header *) (kernel_img + offset);
- memset (header, 0, sizeof (struct grub_module_header));
header->type = grub_host_to_target32 (OBJ_TYPE_ELF);
header->size = grub_host_to_target32 (mod_size + sizeof (*header));
offset += sizeof (*header);
- memset (kernel_img + offset + orig_size, 0, mod_size - orig_size);
grub_util_load_image (p->name, kernel_img + offset);
offset += mod_size;
@@ -1146,7 +1143,6 @@ grub_install_generate_image (const char *dir, const char
*prefix,
curs = grub_util_get_image_size (pubkey_paths[i]);
modules size in mkimage
mkimage sets module size to aligned value; later it is used to actually process it which /may/ lead to inconsistency (as any comparison is against stored aligned size, not actual module size). Same applies to all other embedded types actually. The only one that does it right is pubkey. Just to make sure I do not miss something obvious; otherwise I'll make a patch. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
