similar to: [patch 2/2] xen-gntalloc: signedness bug in add_grefs()

On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git

On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git

On 32 bit systems a high value of op.count could lead to an integer overflow in the kzalloc() and gref_ids would be smaller than expected. If the you triggered another integer overflow in "if (gref_size + op.count > limit)" then you'd probably get memory corruption inside add_grefs(). Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git

The only time when granted pages need to be treated specially is when using Xen''s PTE modification for grant mappings owned by another domain. Otherwise, the area does not require VM_DONTCOPY and VM_PFNMAP, since it can be accessed just like any other page of RAM. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> --- drivers/xen/gntalloc.c | 14 ++++++++++++--

We already have the frame (pfn of the grant page) stored inside struct grant, so there's no need to keep an aditional list of mapped frames for a specific request. This reduces memory usage in blkfront. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: xen-devel@lists.xen.org --- drivers/block/xen-blkfront.c | 6 +-----

Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: xen-devel@lists.xensource.com Cc: netdev@vger.kernel.org --- drivers/net/xen-netfront.c | 34 +++++++++++++++++++--------------- 1 files changed, 19 insertions(+), 15 deletions(-) diff --git

- introduce local variables (shortcuts for frequently used <dom>->grant_table) - adjust first parameter of mapcount() - drop lock acquisition from gnttab_get_version() - remove hard tabs and adjust formatting Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andrew Thomas <andrew.thomas@oracle.com> --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@

Hi sahil: I think the reason why you cannot get page shared is due to the gref you got. Gref is responsible for a page allocated from domU, in my understanding it should not be 0, that is a gref 0 can not be shared, that''s why I skip gref 0 to be nominated. The gref is nominated to Xen and later used to find a corrspond MFN, so it shall not always be the same.

This patch implements persistent grants for the xen-blk{front,back} mechanism. The effect of this change is to reduce the number of unmap operations performed, since they cause a (costly) TLB shootdown. This allows the I/O performance to scale better when a large number of VMs are performing I/O. Previously, the blkfront driver was supplied a bvec[] from the request queue. This was granted to

Hi, I need to use the grant table mechanism, but I can''t find any example regarding how to do it. Could you please provide some examples? Thanks Carlo -- È molto più bello sapere qualcosa di tutto, che sapere tutto di una cosa. Blaise Pascal _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Add a semaphore to protect gnttab_list from exhaustion, and disable callbacks during allocation/free. Fix the network frontend accordingly. Signed-off-by: Samuel Thibault <samuel.thibault@citrix.com> diff -r bb961bda7eff extras/mini-os/gnttab.c --- a/extras/mini-os/gnttab.c Sun Nov 25 21:24:48 2007 +0000 +++ b/extras/mini-os/gnttab.c Mon Nov 26 11:50:31 2007 +0000 @@ -18,6 +18,7 @@

On torsdag 13 september 2018 kl. 12:58:03 EEST George Dunlap wrote: > Dag, > Just verified after a lengthy compilation of the kernel that the patch really works and now I can see a TPM on the virtual side! > Thanks for tracking this down. Any chance you could send a PR to > https://github.com/CentOS-virt7/xen-kernel? I will definitely join that mailing list. Have a feeling this is

Hi I currently would like to find out the signedness of a instruction. But looking at the CBackend, it looks as if it is not that simple? So i have two questions: Is there an easier way than guessing as it is done in the CBackend? Is there a reason for that signedness is not part of the instruction type? Best regards ST

On Tue, Jun 3, 2008 at 2:42 AM, ST <st at iss.tu-darmstadt.de> wrote: > Hi > > I currently would like to find out the signedness of a instruction. But > looking at the CBackend, it looks as if it is not that simple? So i have two > questions: > Is there an easier way than guessing as it is done in the CBackend? > Is there a reason for that signedness is not part of the

Hi, my target handles operands of multiplying instructions differently based on signedness. I wonder then how I would do instruction selection based on the operands signs? The mul instruction sets a nsw for signed, but when i try unsigned ops, there is no wrap flag at all. I'm not sure this is enough information to work with, or? Jonas -------------- next part --------------

Hi Jonas, > my target handles operands of multiplying instructions differently based on > signedness. since the result of a multiply doesn't depend on the signedness, I find it strange that your target differentiates between them. What I'm saying is that if you have (say) two i32 numbers a and b and you do a signed multiply: c = a *s b and an unsigned multiply d = a *u b

Hello, Alberto. > I'm using llvm for instrumenting code, and I need to know if there's a way to > difference between signed and unsigned Values of integer type during an > optimization pass. Types are signless in LLVM 2, operations are not. So, you should probably inspect insts itself, not their operands. -- With best regards, Anton Korobeynikov. Faculty of Mathematics &

The problem is that what i'm instrumenting is loads and stores, plus function call arguments and return values, which have no signedness information. El 26/06/2007, a las 17:03, Anton Korobeynikov escribió: > Hello, Alberto. > >> I'm using llvm for instrumenting code, and I need to know if >> there's a way to >> difference between signed and unsigned

Commit-ID: 8443e57e5ba71e462e31e3b5aad9f7dd1b4736f5 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=8443e57e5ba71e462e31e3b5aad9f7dd1b4736f5 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Tue, 5 Nov 2019 00:39:53 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Tue, 5 Nov 2019 00:44:32 +0000 [klibc] losetup: Fix char signedness

All, Please welcome Zhou Sheng <zhousheng00 at gmail.com> to the LLVM development community. Sheng is from Beijing and is a Masters student at the University there. Sheng and I will be working together on some significant changes to LLVM in the coming months. Our first task is to implement integer types without signs in LLVM. You can read Chris Lattner's notes on this change at this