On Mon, Nov 14, 2016 at 09:20:29PM +0100, Samuel Thibault wrote:
> The following changes since commit 83c83f9a5266ff113060f887f106a47920fa6974:
>
> Merge remote-tracking branch 'bonzini/tags/for-upstream' into staging
> (2016-11-11 12:51:50 +)
>
> are available in the git repository at:
>
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PULL] slirp: Fix access to freed memory
Message-id: 20161114202030.17685-2-samuel.thiba...@ens-lyon.org
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=
On 28 April 2016 at 17:53, Samuel Thibault wrote:
> On Darwin, connect, sendto and friends want the exact size of the sockaddr,
> not more (and in particular, not sizeof(struct sockaddr_storaget))
>
> This commit adds the sockaddr_size helper to be used when passing a sockaddr
> size to such funct
Hello,
Peter Maydell, on Mon 21 Mar 2016 09:48:48 +, wrote:
> Generally the
> process for QEMU is that first patches are sent as normal [PATCH] mails,
> for code review. Patches should only be put into pull requests once
> they've been through the review process. (And then you can batch them
>
On 20 March 2016 at 14:05, Samuel Thibault wrote:
> The following changes since commit 4829e0378dfb91d55af9dfd741bd09e8f2c4f91a:
>
> Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2016-03-18'
> into staging (2016-03-18 17:18:41 +)
>
> are available in the git repository at:
>
>
Ah, sorry, that didn't include the cover letter with the branch to pull
from. I have resent the pull request.
Samuel
On 02/27/2012 09:30 AM, Jan Kiszka wrote:
The following changes since commit b4bd0b168e9f4898b98308f4a8a089f647a86d16:
audio: Add some fall through comments (2012-02-25 18:16:11 +0400)
are available in the git repository at:
git://git.kiszka.org/qemu.git queues/slirp
Pulled. Thanks.
R
On 09/15/2011 05:21 PM, Jan Kiszka wrote:
The following changes since commit 44520db10b1b92f272348ab7028e7afc68ac3edf:
Gdbstub: Fix back-trace on SPARC32 (2011-09-10 18:12:35 +)
are available in the git repository at:
git://git.kiszka.org/qemu.git queues/slirp
Pulled. Thanks.
Rega
On 2011-08-25 16:03, Stefan Weil wrote:
> As I wrote in my last mail, I compared all structs without and with
> -mms-bitfields
> using pahole and codiff. The result is in the appended codiff.log.
>
> About 17 structs changed because of -mms-bitfield. This attribute
> modifies not only
> structs wi
On 08/25/2011 09:03 AM, Stefan Weil wrote:
As I wrote in my last mail, I compared all structs without and with
-mms-bitfields
using pahole and codiff. The result is in the appended codiff.log.
About 17 structs changed because of -mms-bitfield. This attribute
modifies not only
structs with bitfie
As I wrote in my last mail, I compared all structs without and with
-mms-bitfields
using pahole and codiff. The result is in the appended codiff.log.
About 17 structs changed because of -mms-bitfield. This attribute
modifies not only
structs with bitfield but also packed structs or structs with
On 08/25/2011 04:36 PM, Peter Maydell wrote:
On 25 August 2011 14:22, Avi Kivity wrote:
> On 08/25/2011 04:13 PM, Jan Kiszka wrote:
>> Packing all structs is not really a good idea, more a last resort.
>
> btw, how are the non-x86s handling this? by trapping and fixuping in the
> kernel?
If
On 25 August 2011 14:22, Avi Kivity wrote:
> On 08/25/2011 04:13 PM, Jan Kiszka wrote:
>> Packing all structs is not really a good idea, more a last resort.
>
> btw, how are the non-x86s handling this? by trapping and fixuping in the
> kernel?
If a structure's packing means it doesn't adhere to t
On 2011-08-25 15:28, Anthony Liguori wrote:
> On 08/25/2011 08:13 AM, Jan Kiszka wrote:
>> On 2011-08-25 15:06, Anthony Liguori wrote:
>>> On 08/25/2011 07:38 AM, Jan Kiszka wrote:
On 2011-08-25 14:02, TeLeMan wrote:
> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
>> What a mess.
On 08/25/2011 08:13 AM, Jan Kiszka wrote:
On 2011-08-25 15:06, Anthony Liguori wrote:
On 08/25/2011 07:38 AM, Jan Kiszka wrote:
On 2011-08-25 14:02, TeLeMan wrote:
On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
What a mess. Do we really have to go through all 257 packed data
structs
in QE
On 08/25/2011 04:13 PM, Jan Kiszka wrote:
>
> So why can't we just #pragma guard all of the slirp bits? Why are we
> doing it on a per data structure basis?
Packing all structs is not really a good idea, more a last resort.
btw, how are the non-x86s handling this? by trapping and fixuping
On 08/25/2011 04:19 PM, Jan Kiszka wrote:
>
> However, I don't like it either, and prefer the
> __attribute__(((gcc_fields)) as well.
Could someone with a Windows environment test if that (or (packed,
gcc_fields)?) makes
struct {
unsigned char a;
unsigned int b;
};
tr
On 2011-08-25 15:15, Avi Kivity wrote:
> On 08/25/2011 04:07 PM, Anthony Liguori wrote:
>> On 08/25/2011 08:02 AM, Avi Kivity wrote:
>>> On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>
>> What a mess. Do we really have to go through all 257 packed data
structs
>> in QEMU and add th
On 08/25/2011 04:09 PM, Jan Kiszka wrote:
>>
>> We should simply avoid bitfields on externally-defined formats;
>> meanwhile we can use __attribute__((gcc_struct)) and keep using those we
>> have already.
>
> +1
We aren't discussing bitfields anymore but essential unaligned (and
therefore pa
On 08/25/2011 04:07 PM, Anthony Liguori wrote:
On 08/25/2011 08:02 AM, Avi Kivity wrote:
On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>
>> What a mess. Do we really have to go through all 257 packed data
structs
>> in QEMU and add these MS compat bits to all potentially affected
ones?
> I prefe
On 2011-08-25 15:06, Anthony Liguori wrote:
> On 08/25/2011 07:38 AM, Jan Kiszka wrote:
>> On 2011-08-25 14:02, TeLeMan wrote:
>>> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
What a mess. Do we really have to go through all 257 packed data
structs
in QEMU and add these MS compa
On 2011-08-25 15:07, Anthony Liguori wrote:
> On 08/25/2011 08:02 AM, Avi Kivity wrote:
>> On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>> >>
>>> >> What a mess. Do we really have to go through all 257 packed data
>>> structs
>>> >> in QEMU and add these MS compat bits to all potentially affected
>>>
On 08/25/2011 08:02 AM, Avi Kivity wrote:
On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>
>> What a mess. Do we really have to go through all 257 packed data
structs
>> in QEMU and add these MS compat bits to all potentially affected ones?
> I prefer to detect -mms-bitfields and remove it in config
On 08/25/2011 07:38 AM, Jan Kiszka wrote:
On 2011-08-25 14:02, TeLeMan wrote:
On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
What a mess. Do we really have to go through all 257 packed data structs
in QEMU and add these MS compat bits to all potentially affected ones?
I prefer to detect -mm
On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>
>> What a mess. Do we really have to go through all 257 packed data structs
>> in QEMU and add these MS compat bits to all potentially affected ones?
> I prefer to detect -mms-bitfields and remove it in configure.
Can use -mno-ms-bitfields later t
On 2011-08-25 14:02, TeLeMan wrote:
> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
>> On 2011-08-25 03:14, TeLeMan wrote:
>>> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka wrote:
On 2011-08-23 12:49, TeLeMan wrote:
> On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
>> Am 15.08.2011
On Thu, Aug 25, 2011 at 19:04, Jan Kiszka wrote:
> On 2011-08-25 03:14, TeLeMan wrote:
>> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka wrote:
>>> On 2011-08-23 12:49, TeLeMan wrote:
On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>
>> T
On 2011-08-25 03:14, TeLeMan wrote:
> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka wrote:
>> On 2011-08-23 12:49, TeLeMan wrote:
>>> On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
Am 15.08.2011 08:39, schrieb Jan Kiszka:
>
> The following changes since commit
> 3b6ffe50300f13240e
On Wed, Aug 24, 2011 at 17:11, Jan Kiszka wrote:
> On 2011-08-23 12:49, TeLeMan wrote:
>> On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
>>> Am 15.08.2011 08:39, schrieb Jan Kiszka:
The following changes since commit
3b6ffe50300f13240e1b46420ad05da1116df410:
hw/scsi-bu
On 2011-08-23 12:49, TeLeMan wrote:
> On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
>> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>>
>>> The following changes since commit
>>> 3b6ffe50300f13240e1b46420ad05da1116df410:
>>>
>>> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
On Sun, Aug 21, 2011 at 04:00, Stefan Weil wrote:
> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>
>> The following changes since commit
>> 3b6ffe50300f13240e1b46420ad05da1116df410:
>>
>> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
>> +)
>>
>> are available in the git re
Thanks, pulled.
On Mon, Aug 15, 2011 at 6:39 AM, Jan Kiszka wrote:
> The following changes since commit 3b6ffe50300f13240e1b46420ad05da1116df410:
>
> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25 +)
>
> are available in the git repository at:
> git://git.kiszka.org/q
Am 15.08.2011 08:39, schrieb Jan Kiszka:
The following changes since commit
3b6ffe50300f13240e1b46420ad05da1116df410:
hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
+)
are available in the git repository at:
git://git.kiszka.org/qemu.git queues/slirp
Jan Kiszka (1
33 matches
Mail list logo
