Re: [systemd-devel] hash context not closed.

[vcaputo]

On Sat, Feb 03, 2018 at 09:14:40PM +0100, Stef Bon wrote:
> The testing of the new code requires me too much (meson is required..
> and I don't want to replace my existing systemd) and I do not expect
> to add more patches is near future.
> 
> I've got a patch:
> 
> diff --git a/src/basic/gcrypt-util.c b/src/basic/gcrypt-util.c
> index 1bfb77672..c7c07e3b7 100644
> --- a/src/basic/gcrypt-util.c
> +++ b/src/basic/gcrypt-util.c
> @@ -46,6 +46,7 @@ int string_hashsum(const char *s, size_t len, int
> md_algorithm, char **out) {
>  size_t hash_size;
>  void *hash;
>  char *enc;
> +int res=-EIO;
> 
>  initialize_libgcrypt(false);
> 
> @@ -59,14 +60,24 @@ int string_hashsum(const char *s, size_t len, int
> md_algorithm, char **out) {
>  gcry_md_write(md, s, len);
> 
>  hash = gcry_md_read(md, 0);
> +
>  if (!hash)
> -return -EIO;
> +goto closemd;
> 
> +res = -ENOMEM;
>  enc = hexmem(hash, hash_size);
> -if (!enc)
> -return -ENOMEM;
> 
> -*out = enc;
> -return 0;
> +if (enc) {
> +
> +*out = enc;
> +res = 0;
> +
> +}
> +
> +closemd:
> +
> +gcry_md_close(md);
> +
> +return res;
>  }
>  #endif
> 

I'm going to be offline for a few days, so hopefully someone else on the
list will take over here.

Cheers,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] hash context not closed.

[Stef Bon]

The testing of the new code requires me too much (meson is required..
and I don't want to replace my existing systemd) and I do not expect
to add more patches is near future.

I've got a patch:

diff --git a/src/basic/gcrypt-util.c b/src/basic/gcrypt-util.c
index 1bfb77672..c7c07e3b7 100644
--- a/src/basic/gcrypt-util.c
+++ b/src/basic/gcrypt-util.c
@@ -46,6 +46,7 @@ int string_hashsum(const char *s, size_t len, int
md_algorithm, char **out) {
 size_t hash_size;
 void *hash;
 char *enc;
+int res=-EIO;

 initialize_libgcrypt(false);

@@ -59,14 +60,24 @@ int string_hashsum(const char *s, size_t len, int
md_algorithm, char **out) {
 gcry_md_write(md, s, len);

 hash = gcry_md_read(md, 0);
+
 if (!hash)
-return -EIO;
+goto closemd;

+res = -ENOMEM;
 enc = hexmem(hash, hash_size);
-if (!enc)
-return -ENOMEM;

-*out = enc;
-return 0;
+if (enc) {
+
+*out = enc;
+res = 0;
+
+}
+
+closemd:
+
+gcry_md_close(md);
+
+return res;
 }
 #endif

Stef
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] hash context not closed.

[vcaputo]

On Sat, Feb 03, 2018 at 08:38:38PM +0100, Stef Bon wrote:
> 2018-02-03 20:27 GMT+01:00  :
> 
> >
> > Nice catch, that indeed looks like a leak.  Would you like to prep a
> > PR fixing it?
> >
> 
> PR? I do not know what you mean. A pull request?
> I can write a patch.

The systemd project uses github.  You can create a free github account
if you don't already have one, clone the systemd project to your
account, then push your patch to your cloned repo on github using git.

Once pushed, you create a pull request (PR) of your changes on github
for the systemd project, where we'll be able to review and merge it in
the normal workflow.

If you haven't done this before, it can seem a bit onerous at first.
It's not that bad though, and you'll then be positioned to readily
participate in the abundance of open development occurring on the
platform, in addition to future systemd contributions.

Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] hash context not closed.

[Stef Bon]

2018-02-03 20:27 GMT+01:00  :

>
> Nice catch, that indeed looks like a leak.  Would you like to prep a
> PR fixing it?
>

PR? I do not know what you mean. A pull request?
I can write a patch.

Stef
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] hash context not closed.

[vcaputo]

On Sat, Feb 03, 2018 at 07:26:24PM +0100, Stef Bon wrote:
> Hi,
> 
> when I look at the function string_hashsum it looks like the context
> is not closed when done.
> 
> After a succesfull gcry_md_open the hash context md should be closed
> when leaving this function. That does not happen.
> 

Nice catch, that indeed looks like a leak.  Would you like to prep a
PR fixing it?

Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] hash context not closed.

[Stef Bon]

2018-02-03 19:26 GMT+01:00 Stef Bon :
> Hi,

Oh and this in in file src/basic/gcrypt-util.c.

>
> Stef
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] hash context not closed.

[Stef Bon]

Hi,

when I look at the function string_hashsum it looks like the context
is not closed when done.

After a succesfull gcry_md_open the hash context md should be closed
when leaving this function. That does not happen.

Stef
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Improvement of Battery Drain DELL Notebook XPS-13 9365 Possible?!

[Axel Klein]

Hi *,

On my Dell XPS-13 9365k Notebook I experience pretty accurately a
battery drain of 5% per hour in suspend when running Ubuntu.

Compared to this 5% per hour battery drain while in sleep, I've found a
maximum battery drain of 2-3% independent of sleep time when the Dell
Notebook 9365 runs Windows, which is a huge benefit. On Windows I can
afford putting the notebook to sleep always, whereas on Ubuntu I have to
balance the choice with the time I expect the machine being down - a big
drawback.

I assume 'they' (on Windows) have a mechanism in place that changes the
state to 'hibernate' after a certain time. For example when I wake up
the 9365 after half an hour from sleep, it comes back very quickly, and
when I wake it up after one hour from sleep it goes through a booting
process that takes much more time.

If this is true, I am asking whether we could have a similar behavior
running Linux on these machines.
To me such a procedure looks very sensible: Having it waking up very
quickly within half an hour or so and limiting the battery drain to a
couple of percents.
This is exactly what I would wish.

So I am asking whether we could have a similar behavior running Linux on
this machines?

By the way: Is this the right location to ask such a question?

Thank you in advance for your time and effort to look into this.

Best regards
Axel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel