same effect and
discovered that we only have PIC ops hooked up because kernel bypasses[2]
PIC enumeration because PCAT_COMPAT is set. Which is wrong for TDX guest
or other platforms without PIC.
I am not aware about any user-visible issues due to it, but maybe they are
just not discovered yet.
[1]
https://lore.kernel.org/linux-kernel/b29f00c1eb5cff585ec2b999b69923c13418ecc4.1619458733.git.sathyanarayanan.kuppusw...@linux.intel.com/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/i8259.c#n322
--
Kiryl Shutsemau / Kirill A. Shutemov
On Wed, Apr 12, 2023 at 06:07:28PM -0700, Sean Christopherson wrote:
> On Wed, Jan 25, 2023, Kirill A. Shutemov wrote:
> > On Wed, Jan 25, 2023 at 12:20:26AM +, Sean Christopherson wrote:
> > > On Tue, Jan 24, 2023, Liam Merwick wrote:
> > > > On 14/01/2023 00
return -EINVAL;
> +
> + return restrictedmem_create_on_user_mount(mount_fd);
> + } else {
> + return restrictedmem_create(NULL);
> + }
Maybe restructure with single restrictedmem_create() call?
struct vfsmount *mnt = NULL;
if (flags == RMFD_USERMNT) {
...
mnt = ...();
}
return restrictedmem_create(mnt);
> +}
> +
> int restrictedmem_bind(struct file *file, pgoff_t start, pgoff_t end,
> struct restrictedmem_notifier *notifier, bool exclusive)
> {
> --
> 2.40.0.348.gf938b09366-goog
--
Kiryl Shutsemau / Kirill A. Shutemov
vide string that
contains mount path or fd that represents the filesystem (returned from
fsmount(2) or open_tree(2)).
fd seems more flexible: it allows to specify unbind mounts.
--
Kiryl Shutsemau / Kirill A. Shutemov
}
+
+ rm = inode->i_mapping->private_data;
+ memfd = rm->memfd;
+
+ if (memfd->f_mapping != mapping) {
+ spin_unlock(&inode->i_lock);
+ continue;
+ }
+ spin_unlock(&inode->i_lock);
+
xa_for_each_range(&rm->bindings, index, notifier, start, end)
notifier->ops->error(notifier, start, end);
break;
--
Kiryl Shutsemau / Kirill A. Shutemov
r_remove_page(struct address_space
*mapping,
return 0;
}
-const struct address_space_operations shmem_aops = {
+static const struct address_space_operations shmem_aops = {
.writepage = shmem_writepage,
.dirty_folio= noop_dirty_folio,
#ifdef CONFIG_TMPFS
@@ -3906,7 +3906,6 @@ const struct address_space_operations shmem_aops = {
#endif
.error_remove_page = shmem_error_remove_page,
};
-EXPORT_SYMBOL(shmem_aops);
static const struct file_operations shmem_file_operations = {
.mmap = shmem_mmap,
--
Kiryl Shutsemau / Kirill A. Shutemov
creating and undoing migration entries in the userspace page tables
> as there's no mmap). Elevated refcount on the other hand is detected
> very early in compaction so no isolation is attempted, so from that
> aspect it's optimal.
Hm. Do we need a new hook in a_ops to check if the page is migratable
before going with longer path to migrate_page().
Or maybe add AS_UNMOVABLE?
--
Kiryl Shutsemau / Kirill A. Shutemov
16943c73..4ef60ba7eb1d 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -2304,7 +2304,7 @@ static inline void kvm_account_pgtable_pages(void *virt,
int nr)
#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t
gfn)
{
- lockdep_assert_held(kvm->mmu_lock);
+ lockdep_assert_held(&kvm->mmu_lock);
return xa_to_value(xa_load(&kvm->mem_attr_array, gfn));
}
--
Kiryl Shutsemau / Kirill A. Shutemov
x27;t help unless file based
> > advise for hugepage allocation is implemented.
>
> Had a look at fadvise() and looks it does not support HUGEPAGE for any
> filesystem yet.
Yes, I think fadvise() is the right direction here. The problem is similar
to NUMA policy where existing APIs are focused around virtual memory
addresses. We need to extend ABI to take fd+offset as input instead.
--
Kiryl Shutsemau / Kirill A. Shutemov
On Mon, Nov 28, 2022 at 06:06:32PM -0600, Michael Roth wrote:
> On Tue, Oct 25, 2022 at 11:13:37PM +0800, Chao Peng wrote:
> > From: "Kirill A. Shutemov"
> >
>
>
>
> > +static struct file *restrictedmem_file_create(struct file *memfd)
> &
On Wed, Nov 09, 2022 at 06:54:04PM +0300, Kirill A. Shutemov wrote:
> On Mon, Nov 07, 2022 at 04:41:41PM -0800, Isaku Yamahata wrote:
> > On Thu, Nov 03, 2022 at 05:43:52PM +0530,
> > Vishal Annapurve wrote:
> >
> > > On Tue, Oct 25, 2022 at 8:48 PM Chao Peng
>
sues there and still
> >chance for splitting directmap over time.
>
> I've been hoping that
>
> c) using a mechanism such as [1] [2] where the goal is to group together
> these small allocations that need to increase directmap granularity so
> maximum number of large mappings are preserved.
As I mentioned in the other thread the restricted memfd can be backed by
secretmem instead of plain memfd. It already handles directmap with care.
But I don't think it has to be part of initial restricted memfd
implementation. It is SEV-specific requirement and AMD folks can extend
implementation as needed later.
--
Kiryl Shutsemau / Kirill A. Shutemov
r possible user of
restricted memfd.
I tried to find a way to get it right: we need to get restricted memfd
code info about corrupted page so it can invalidate its users. On the next
request of the page the user will see an error. In case of KVM, the error
will likely escalate to SIGBUS.
The problem is that core-mm code that handles memory failure knows nothing
about restricted memfd. It only sees that the page belongs to a normal
memfd.
AFAICS, there's no way to get it intercepted from the shim level. shmem
code has to be patches. shmem_error_remove_page() has to call into
restricted memfd code.
Hugh, are you okay with this? Or maybe you have a better idea?
--
Kiryl Shutsemau / Kirill A. Shutemov
On Wed, Nov 02, 2022 at 05:07:00PM -0500, Michael Roth wrote:
> On Thu, Nov 03, 2022 at 12:14:04AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Oct 31, 2022 at 12:47:38PM -0500, Michael Roth wrote:
> > >
> > > In v8 there was some discussion about potentially passi
t documentation if there's any?
--
Kiryl Shutsemau / Kirill A. Shutemov
node/fd?
fmove_pages(2) should be relatively straight forward, since it is
best-effort and does not guarantee that the page will note be moved
somewhare else just after return from the syscall.
--
Kiryl Shutsemau / Kirill A. Shutemov
On Tue, Oct 18, 2022 at 07:12:10PM +0530, Vishal Annapurve wrote:
> On Tue, Oct 18, 2022 at 3:27 AM Kirill A . Shutemov
> wrote:
> >
> > On Mon, Oct 17, 2022 at 06:39:06PM +0200, Gupta, Pankaj wrote:
> > > On 10/17/2022 6:19 PM, Kirill A . Shutemov wrote:
> >
On Mon, Oct 17, 2022 at 06:39:06PM +0200, Gupta, Pankaj wrote:
> On 10/17/2022 6:19 PM, Kirill A . Shutemov wrote:
> > On Mon, Oct 17, 2022 at 03:00:21PM +0200, Vlastimil Babka wrote:
> > > On 9/15/22 16:29, Chao Peng wrote:
> > > > From: "Kirill A. Shutemov&q
On Mon, Oct 17, 2022 at 03:00:21PM +0200, Vlastimil Babka wrote:
> On 9/15/22 16:29, Chao Peng wrote:
> > From: "Kirill A. Shutemov"
> >
> > KVM can use memfd-provided memory for guest memory. For normal userspace
> > accessible memory, KVM userspace
gt; > +
> > + inode->i_mode |= S_IFREG;
> > + inode->i_op = &inaccessible_iops;
> > + inode->i_mapping->private_data = data;
> > +
> > + file = alloc_file_pseudo(inode, inaccessible_mnt,
> > +"[memfd:inaccessible]", O_RDWR,
> > +&inaccessible_fops);
> > + if (IS_ERR(file)) {
> > + iput(inode);
> > + kfree(data);
>
> I think this might be missing a return at this point.
Good catch! Thanks!
--
Kiryl Shutsemau / Kirill A. Shutemov
fd if it is now inaccessible. It should be trivial by
checking file->f_inode->i_sb->s_magic.
--
Kiryl Shutsemau / Kirill A. Shutemov
notifiers);
> > + mutex_unlock(&data->lock);
> > +}
> > +EXPORT_SYMBOL_GPL(inaccessible_register_notifier);
>
> If the memfd wasn't marked as inaccessible, or more generally
> speaking, if the file isn't a memfd_inaccessible file, this ends up
> accessing an uninitialized pointer for the notifier list. Should there
> be a check for that here, and have this function return an error if
> that's not the case?
I think it is "don't do that" category. inaccessible_register_notifier()
caller has to know what file it operates on, no?
--
Kiryl Shutsemau / Kirill A. Shutemov
On Tue, Sep 27, 2022 at 11:23:24PM +, Sean Christopherson wrote:
> On Mon, Sep 26, 2022, David Hildenbrand wrote:
> > On 26.09.22 16:48, Kirill A. Shutemov wrote:
> > > On Mon, Sep 26, 2022 at 12:35:34PM +0200, David Hildenbrand wrote:
> > > > When using DAX
On Mon, Sep 26, 2022 at 12:35:34PM +0200, David Hildenbrand wrote:
> On 23.09.22 02:58, Kirill A . Shutemov wrote:
> > On Mon, Sep 19, 2022 at 11:12:46AM +0200, David Hildenbrand wrote:
> > > > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
>
user in sight (especially how to get the memfd
> from even allocating such memory which will require bigger changes), I
> prefer to keep it simple here and work on pages/folios. No need to
> over-complicate it for now.
Sean, Paolo , what is your take on this? Do you have conrete use case of
pageless backend for the mechanism in sight? Maybe DAX?
--
Kiryl Shutsemau / Kirill A. Shutemov
gt; force
> KVM to rediscover the info on its own.
I guess we can allow order pointer to be NULL to cover caller that don't
need to know the order. Is it useful?
--
Kiryl Shutsemau / Kirill A. Shutemov
he actual check.
validate_mmap_request() is in mm/nommu.c which is not relevant for real
computers.
I was talking about this check:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/mmap.c#n1495
--
Kiryl Shutsemau / Kirill A. Shutemov
On Tue, Sep 13, 2022 at 09:44:27AM +, Sean Christopherson wrote:
> On Thu, Sep 08, 2022, Kirill A. Shutemov wrote:
> > On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:
> > > On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:
> > >
On Fri, Sep 09, 2022 at 12:11:05PM -0700, Andy Lutomirski wrote:
>
>
> On Fri, Sep 9, 2022, at 7:32 AM, Kirill A . Shutemov wrote:
> > On Thu, Sep 08, 2022 at 09:48:35PM -0700, Andy Lutomirski wrote:
> >> On 8/19/22 17:27, Kirill A. Shutemov wrote:
> >> > On T
On Thu, Sep 08, 2022 at 09:48:35PM -0700, Andy Lutomirski wrote:
> On 8/19/22 17:27, Kirill A. Shutemov wrote:
> > On Thu, Aug 18, 2022 at 08:00:41PM -0700, Hugh Dickins wrote:
> > > On Thu, 18 Aug 2022, Kirill A . Shutemov wrote:
> > > > On Wed, Aug 17, 2022 at
On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:
> On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:
> > > I will try next week to rework it as shim to top of shmem. Does it work
> > > for you?
> >
> > Yes, please do, thanks.
n different processes that point to the same struct
file.
[1]
https://lore.kernel.org/all/20220831142439.65q2gi4g2d2z4...@box.shutemov.name
--
Kiryl Shutsemau / Kirill A. Shutemov
gt;
> + inaccessible_file->f_flags |= O_LARGEFILE;
> +
Good catch. Thanks.
I will modify memfd_mkinaccessible() to do this.
--
Kiryl Shutsemau / Kirill A. Shutemov
+
+void inaccessible_put_pfn(struct file *file, pfn_t pfn)
+{
+ struct page *page = pfn_t_to_page(pfn);
+ struct inaccessible_data *data = file->f_mapping->private_data;
+
+ if (WARN_ON_ONCE(!page))
+ return;
+
+ SetPageUptodate(page);
+ unlock_page(page);
+ put_page(page);
+ up_read(&data->lock);
+}
+EXPORT_SYMBOL_GPL(inaccessible_put_pfn);
--
Kiryl Shutsemau / Kirill A. Shutemov
On Thu, Aug 18, 2022 at 08:00:41PM -0700, Hugh Dickins wrote:
> On Thu, 18 Aug 2022, Kirill A . Shutemov wrote:
> > On Wed, Aug 17, 2022 at 10:40:12PM -0700, Hugh Dickins wrote:
> > >
> > > If your memory could be swapped, that would be enough of a good reason
> >
s wrong. Page has be locked until it lends into SEPT and
must make it dirty before unlocking.
--
Kiryl Shutsemau / Kirill A. Shutemov
t direction. We risk creating yet
another parallel VM with own rules/locking/accounting that opaque to
core-mm.
Note that on machines that run TDX guests such memory would likely be the
bulk of memory use. Treating it as a fringe case may bite us one day.
--
Kiryl Shutsemau / Kirill A. Shutemov
domly and
therefore incompatible with F_SEAL_AUTO_ALLOCATE intent?
Note, that userfaultfd is only relevant for shared memory as it requires
VMA which we don't have for MFD_INACCESSIBLE.
--
Kiryl Shutsemau / Kirill A. Shutemov
host memory. I mean acceptance happens after host memory
allocation but they are not in lockstep, acceptance can happen much later.
--
Kiryl Shutsemau / Kirill A. Shutemov
ges as needed. I'm not
sure if anybody volunteer to work on BIOS code to make it happen.
Hm.
--
Kirill A. Shutemov
On Tue, Apr 12, 2022 at 09:39:25PM +0800, Chao Peng wrote:
> On Mon, Apr 11, 2022 at 06:32:33PM +0300, Kirill A. Shutemov wrote:
> > On Thu, Apr 07, 2022 at 04:05:36PM +, Sean Christopherson wrote:
> > > Hmm, shmem_writepage() already handles SHM_F_INACCESSIBLE by rejecting
-ENOTSUPP for
address_space_operations::migratepage().
What's wrong with that approach?
--
Kirill A. Shutemov
n't die later
> > with
> > exceptions and/or data corruption (pre-SNP SEV guests) in the guest.
>
> SHM_LOCK sounds like a good match.
Emm, no. shmctl(2) and SHM_LOCK are SysV IPC thing. I don't see how they
fit here.
--
Kirill A. Shutemov
On Thu, Mar 10, 2022 at 10:08:59PM +0800, Chao Peng wrote:
> From: "Kirill A. Shutemov"
>
> Introduce a new memfd_create() flag indicating the content of the
> created memfd is inaccessible from userspace through ordinary MMU
> access (e.g., read/write/mmap). However
allocate(&info->memfile_notifiers, start, end);
> +#endif
All these #ifdefs look ugly. Could you provide dummy memfile_* for
!MEMFILE_NOTIFIER case?
--
Kirill A. Shutemov
On Thu, Apr 07, 2022 at 06:38:40PM +0200, Paolo Bonzini wrote:
> On 4/7/22 17:27, Kirill A. Shutemov wrote:
> > On Thu, Apr 07, 2022 at 07:28:54AM -0700, Richard Henderson wrote:
> > > On 4/7/22 06:18, Kirill A. Shutemov wrote:
> > > > > The new hook is incor
On Thu, Apr 07, 2022 at 07:28:54AM -0700, Richard Henderson wrote:
> On 4/7/22 06:18, Kirill A. Shutemov wrote:
> > > The new hook is incorrect, in that it doesn't apply to addresses along
> > > the tlb fast path.
> >
> > I'm not sure what you mean b
On Wed, Apr 06, 2022 at 10:34:41PM -0500, Richard Henderson wrote:
> On 4/6/22 20:01, Kirill A. Shutemov wrote:
> > Linear Address Masking feature makes CPU ignore some bits of the virtual
> > address. These bits can be used to encode metadata.
> >
> > The feature is
strips address from the metadata bits and gets it to canonical
shape before handling memory access. It has to be done very early before
TLB lookup.
Signed-off-by: Kirill A. Shutemov
---
accel/tcg/cputlb.c | 20 +---
include/hw/core/tcg-cpu-ops.h| 5
h. The struct kvm can be freed and re-allocated
from the slab and this function will give false-negetive.
Maybe the kvm has to be tagged with a sequential id that incremented every
allocation. This id can be checked here.
> +
> + return true;
> +}
--
Kirill A. Shutemov
On Fri, Nov 19, 2021 at 02:51:11PM +0100, David Hildenbrand wrote:
> On 19.11.21 14:47, Chao Peng wrote:
> > From: "Kirill A. Shutemov"
> >
> > The new seal type provides semantics required for KVM guest private
> > memory support. A file descriptor with th
On Thu, Nov 11, 2021 at 10:13:40PM +0800, Chao Peng wrote:
> The new seal is only allowed if there's no pre-existing pages in the fd
> and there's no existing mapping of the file. After the seal is set, no
> read/write/mmap from userspace is allowed.
>
> Signed-o
Looks like this patchset got stuck and never reached upsteam.
Any update on this?
--
Kirill A. Shutemov
fix this by teaching mux to send an event to the frontend with
> the focus.
>
> Reported-by: Kirill A. Shutemov
> Signed-off-by: Marc-André Lureau
> Fixes: a4afa548fc6d ("char: move front end handlers in CharBackend")
Works for me.
Tested-by: Kirill A. Shutemov
--
Kirill A. Shutemov
d
handlers in CharBackend"). Since the commit the qemu_chr_be_event()
failed to deliver CHR_EVENT_BREAK due to qemu_chr_fe_init() forgot to
get s->be initialized in case of mux.
Let's fix this.
Signed-off-by: Kirill A. Shutemov
Fixes: a4afa548fc6d ("char: move front end handler
On Fri, Dec 16, 2016 at 01:59:36PM +0100, Paolo Bonzini wrote:
>
>
> On 15/12/2016 01:13, Kirill A. Shutemov wrote:
> > The new paging more is extension of IA32e mode with more additional page
> > table level.
> >
> > It brings support of 57-bit vitrual
On Fri, Dec 16, 2016 at 01:59:36PM +0100, Paolo Bonzini wrote:
>
>
> On 15/12/2016 01:13, Kirill A. Shutemov wrote:
> > The new paging more is extension of IA32e mode with more additional page
> > table level.
> >
> > It brings support of 57-bit vitrual
=0):ECX[bit 16].
CR4.LA57[bit 12] need to be set when pageing enables to activate 5-level
paging mode.
Signed-off-by: Kirill A. Shutemov
---
target-i386/arch_memory_mapping.c | 42 ++-
target-i386/cpu.c | 16 ++-
target-i386/cpu.h | 2 +
target-i386
=0):ECX[bit 16].
CR4.LA57[bit 12] need to be set when pageing enables to activate 5-level
paging mode.
Signed-off-by: Kirill A. Shutemov
Cc: qemu-devel@nongnu.org
---
target-i386/arch_memory_mapping.c | 42 --
target-i386/cpu.c | 16 ++--
target-i386/cpu.h
On Wed, Apr 27, 2016 at 04:59:57PM +0200, Andrea Arcangeli wrote:
> On Wed, Apr 27, 2016 at 04:50:30PM +0300, Kirill A. Shutemov wrote:
> > I know nothing about kvm. How do you protect against pmd splitting between
> > get_user_pages() and the check?
>
> get_user_pages_fast(
cific, doesn't it?
> +static inline int PageTransCompoundMap(struct page *page)
> +{
> + return PageTransCompound(page) && atomic_read(&page->_mapcount) < 0;
> +}
> +
> +/*
> * PageTransTail returns true for both transparent huge pages
> * and hugetlbfs pages, so it should only be called when it's known
> * that hugetlbfs pages aren't involved.
> @@ -559,6 +580,7 @@ static inline int TestClearPageDoubleMap(struct page
> *page)
> #else
> TESTPAGEFLAG_FALSE(TransHuge)
> TESTPAGEFLAG_FALSE(TransCompound)
> +TESTPAGEFLAG_FALSE(TransCompoundMap)
> TESTPAGEFLAG_FALSE(TransTail)
> TESTPAGEFLAG_FALSE(DoubleMap)
> TESTSETFLAG_FALSE(DoubleMap)
--
Kirill A. Shutemov
On Fri, Apr 15, 2016 at 02:42:33PM +0100, Dr. David Alan Gilbert wrote:
> * Kirill A. Shutemov (kir...@shutemov.name) wrote:
> > On Thu, Apr 14, 2016 at 12:22:30PM -0400, Andrea Arcangeli wrote:
> > > Adding linux-mm too,
> > >
> > > On Thu, Apr 14, 2016
e improved too, so there is a
> simpler way to reproduce than running precopy before postcopy in qemu.
I've tested current Linus' tree and v4.5 using qemu postcopy test case for
both x86-64 and i386 and it never failed for me:
/x86_64/postcopy: first_byte = 7e last_byte = 7d hit_edge = 1 OK
OK
/i386/postcopy: first_byte = f6 last_byte = f5 hit_edge = 1 OK
OK
I've run it directly, setting relevant QTEST_QEMU_BINARY.
--
Kirill A. Shutemov
On Tue, Oct 07, 2014 at 03:24:58PM +0200, Andrea Arcangeli wrote:
> Hi Kirill,
>
> On Tue, Oct 07, 2014 at 01:36:45PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Oct 03, 2014 at 07:07:58PM +0200, Andrea Arcangeli wrote:
> > > MADV_USERFAULT is a new madvise flag that will
On Tue, Oct 07, 2014 at 12:01:02PM +0100, Dr. David Alan Gilbert wrote:
> * Kirill A. Shutemov (kir...@shutemov.name) wrote:
> > On Tue, Oct 07, 2014 at 11:46:04AM +0100, Dr. David Alan Gilbert wrote:
> > > * Kirill A. Shutemov (kir...@shutemov.name) wrote:
> > > >
triggering COW instead of adding limitation on
pages' mapcount? The limitation looks artificial from interface POV.
--
Kirill A. Shutemov
On Tue, Oct 07, 2014 at 11:46:04AM +0100, Dr. David Alan Gilbert wrote:
> * Kirill A. Shutemov (kir...@shutemov.name) wrote:
> > On Fri, Oct 03, 2014 at 07:07:58PM +0200, Andrea Arcangeli wrote:
> > > MADV_USERFAULT is a new madvise flag that will set VM_USERFAULT in the
> &g
ich
may or may not trigger an action from kernel side. I don't think an
application will behaive reasonably if kernel ignore the *advise* and will
not send SIGBUS, but allocate memory.
I would suggest to consider to use some other interface for the
functionality: a new syscall or, perhaps, mpr
; /*
>* In case if we meet a flag we don't know about.
>*/
> - [0 ... (BITS_PER_LONG-1)] = "??",
> + [0 ... (BITS_PER_LONG)] = "??",
>
> [ilog2(VM_READ)]= "rd",
> [ilog2(VM_WRITE)] = "wr",
--
Kirill A. Shutemov
Currently we silently ignore getversion requests for anything except
file or directory. Let's instead return ENOTTY error to indicate that
getversion is not supported. It makes implementation consistent on
all not-supported cases.
Signed-off-by: Kirill A. Shutemov
---
hw/9pfs/virtio-9p-han
The solution is to make P9_STATS_GEN failure non-fatal
for getattr request. Just don't set P9_STATS_GEN flag in result mask on
failure.
Signed-off-by: Kirill A. Shutemov
---
hw/9pfs/cofile.c| 4
hw/9pfs/virtio-9p.c | 12 ++--
2 files changed, 10 insertions(+), 6 deletions
All get_st_gen() implementations except handle_ioc_getversion() have
guard for undefined FS_IOC_GETVERSION. Let's add it there too.
Signed-off-by: Kirill A. Shutemov
---
hw/9pfs/virtio-9p-handle.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/9pfs/virtio-9p-handle.c b/hw
v9fs_co_st_gen() expects to see error code in errno, not in return code.
Let's fix this.
Signed-off-by: Kirill A. Shutemov
---
hw/9pfs/virtio-9p-local.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c
Michael S. Tsirkin wrote:
> On Tue, Jan 28, 2014 at 12:55:51PM +0200, Kirill A. Shutemov wrote:
> > Currently we have few issues with P9_STATS_GEN:
> >
> > - We don't try to read st_gen anything except files or directories, but
> >still set P9_STATS_GEN bit i
issues and cleanup code a bit.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Daniel P. Berrange
Reviewed-by: Aneesh Kumar K.V
---
hw/9pfs/cofile.c | 4
hw/9pfs/virtio-9p-handle.c | 8 +++-
hw/9pfs/virtio-9p-local.c | 10 ++
hw/9pfs/virtio-9p-proxy.c | 3 ++-
hw/9pfs/v
Aneesh Kumar K.V wrote:
> "Kirill A. Shutemov" writes:
>
> > Kirill A. Shutemov wrote:
> >> Currently we have few issues with P9_STATS_GEN:
> >>
> >> - We don't try to read st_gen anything except files or directories, but
> >>
Kirill A. Shutemov wrote:
> Currently we have few issues with P9_STATS_GEN:
>
> - We don't try to read st_gen anything except files or directories, but
>still set P9_STATS_GEN bit in st_result_mask. It may mislead client:
>we present garbage as valid st_gen.
>
&
issues and cleanup code a bit.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Daniel P. Berrange
Reviewed-by: Aneesh Kumar K.V
---
hw/9pfs/cofile.c | 4
hw/9pfs/virtio-9p-handle.c | 8 +++-
hw/9pfs/virtio-9p-local.c | 10 ++
hw/9pfs/virtio-9p-proxy.c | 3 ++-
hw/9pfs/v
On Wed, Nov 06, 2013 at 09:41:47PM +0530, Aneesh Kumar K.V wrote:
> "Kirill A. Shutemov" writes:
>
> > From: "Kirill A. Shutemov"
> >
> > Currently we have few issues with P9_STATS_GEN:
> >
> > - We don't try to read st_g
From: "Kirill A. Shutemov"
Currently we have few issues with P9_STATS_GEN:
- We don't try to read st_gen anything except files or directories, but
still set P9_STATS_GEN bit in st_result_mask. It may mislead client:
we present garbage as valid st_gen.
- If we failed to g
On Sun, Oct 27, 2013 at 03:41:34AM +0300, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
>
> Currently we have few issues with P9_STATS_GEN:
>
> - We don't try to read st_gen anything except files or directories, but
>still set P9_STATS_GEN bit
From: "Kirill A. Shutemov"
Currently we have few issues with P9_STATS_GEN:
- We don't try to read st_gen anything except files or directories, but
still set P9_STATS_GEN bit in st_result_mask. It may mislead client:
we present garbage as valid st_gen.
- If we failed to g
issues and cleanup code a bit.
Signed-off-by: Kirill A. Shutemov
---
hw/9pfs/cofile.c | 4
hw/9pfs/virtio-9p-handle.c | 8 +++-
hw/9pfs/virtio-9p-local.c | 10 ++
hw/9pfs/virtio-9p-proxy.c | 3 ++-
hw/9pfs/virtio-9p.c| 12 ++--
5 files changed, 25 inserti
2010/1/20 Gleb Natapov :
> On Wed, Jan 20, 2010 at 02:03:04PM +0100, Markus Armbruster wrote:
>> "Kirill A. Shutemov" writes:
>> > No, compiler can't add anything between. 'char' is always byte-aligned.
>>
>> You got some reading to do then
On Wed, Jan 20, 2010 at 3:03 PM, Markus Armbruster wrote:
> "Kirill A. Shutemov" writes:
>> No, compiler can't add anything between. 'char' is always byte-aligned.
>
> You got some reading to do then.
Do you want to say that it's not true? Could
On Wed, Jan 20, 2010 at 2:15 PM, Markus Armbruster wrote:
> Kevin Wolf writes:
>
>> Am 20.01.2010 12:09, schrieb Kirill A. Shutemov:
>>> On Wed, Jan 20, 2010 at 12:33 PM, Daniel P. Berrange
>>> wrote:
>>>> On Wed, Jan 20, 2010 at 08:19:26AM +0200, Kiri
On Wed, Jan 20, 2010 at 12:33 PM, Daniel P. Berrange
wrote:
> On Wed, Jan 20, 2010 at 08:19:26AM +0200, Kirill A. Shutemov wrote:
>> On Wed, Jan 20, 2010 at 1:56 AM, Juan Quintela wrote:
>> > From: Kirill A. Shutemov
>> >
>> > CC block/vvfat.o
>&g
On Wed, Jan 20, 2010 at 1:56 AM, Juan Quintela wrote:
> From: Kirill A. Shutemov
>
> CC block/vvfat.o
> cc1: warnings being treated as errors
> block/vvfat.c: In function 'commit_one_file':
> block/vvfat.c:2259: error: ignoring return value of 'ftrun
On Tue, Jan 19, 2010 at 2:11 PM, Juan Quintela wrote:
> "Kirill A. Shutemov" wrote:
>> A variant of write(2) which handles partial write.
>>
>> Signed-off-by: Kirill A. Shutemov
>
> Hi
>
> Have you updated this series? Is there any reason that you kno
On Tue, Jan 5, 2010 at 4:42 PM, Juan Quintela wrote:
> "Kirill A. Shutemov" wrote:
>> CC usb-linux.o
>> cc1: warnings being treated as errors
>> usb-linux.c: In function 'usb_host_read_file':
>> usb-linux.c:1204: error: ignoring retur
mmap_frag() returns -1 on error and set errno.
Signed-off-by: Kirill A. Shutemov
---
linux-user/mmap.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index c1c7e48..47bc339 100644
--- a/linux-user/mmap.c
+++ b/linux-user
-fstack-protector-all emit extra code to check for buffer overflows,
such as stack smashing attacks. This is done by adding a guard
variable to functions with vulnerable objects.
Signed-off-by: Kirill A. Shutemov
---
configure |8
1 files changed, 8 insertions(+), 0 deletions
_FORTIFY_SOURCE is a Glibc feature which adds memory and string function
protection.
Signed-off-by: Kirill A. Shutemov
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 18aed43..0cdcdb3 100755
--- a/configure
+++ b/configure
_result
/usr/src/RPM/BUILD/qemu-0.11.92/linux-user/mmap.c: In function 'target_mmap':
/usr/src/RPM/BUILD/qemu-0.11.92/linux-user/mmap.c:477: error: ignoring return
value of 'pread', declared with attribute warn_unused_result
make[1]: *** [mmap.o] Error 1
Signed-off-by: Kirill A
th attribute warn_unused_result
/usr/src/RPM/BUILD/qemu-0.11.92/vl.c:6083: error: ignoring return value of
'chdir', declared with attribute warn_unused_result
make[1]: *** [vl.o] Error 1
Signed-off-by: Kirill A. Shutemov
---
vl.c | 33 +
1 files cha
t
/usr/src/RPM/BUILD/qemu-0.11.92/monitor.c: In function
'do_physical_memory_save':
/usr/src/RPM/BUILD/qemu-0.11.92/monitor.c:1345: error: ignoring return value of
'fwrite', declared with attribute warn_unused_result
make[1]: *** [monitor.o] Error 1
Signed-off-by: K
CCusb-linux.o
cc1: warnings being treated as errors
usb-linux.c: In function 'usb_host_read_file':
usb-linux.c:1204: error: ignoring return value of 'fgets', declared with
attribute warn_unused_result
make: *** [usb-linux.o] Error 1
Signed-off-by: Kirill A. Shutem
CCnet/slirp.o
cc1: warnings being treated as errors
net/slirp.c: In function 'slirp_smb_cleanup':
net/slirp.c:470: error: ignoring return value of 'system', declared with
attribute warn_unused_result
make: *** [net/slirp.o] Error 1
Signed-off-by: Kirill A. Shutemov
---
ute warn_unused_result
block/qcow2.c:855: error: ignoring return value of 'write', declared with
attribute warn_unused_result
make: *** [block/qcow2.o] Error 1
Signed-off-by: Kirill A. Shutemov
---
block/qcow2.c | 55 +--
1 files changed, 4
068:
/usr/include/bits/stdio2.h:65: error: call to __builtin___snprintf_chk will
always overflow destination buffer
make: *** [block/vvfat.o] Error 1
Signed-off-by: Kirill A. Shutemov
---
block/vvfat.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
1 - 100 of 218 matches
Mail list logo
