t 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
rn -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
g 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
continue;
+ spin_lock(>i_lock);
+ if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
+ spin_unlock(>i_lock);
+ continue;
+ }
+
+ rm = inode->i_mapping->private_data;
+ memfd = rm->memfd;
+
+ if (memfd->f_mapping != mapping) {
+ spin_unlock(>i_lock);
+ continue;
+ }
+ spin_unlock(>i_lock);
+
xa_for_each_range(>bindings, index, notifier, start, end)
notifier->ops->error(notifier, start, end);
break;
--
Kiryl Shutsemau / Kirill A. Shutemov
em_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
es 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
e/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(>mmu_lock);
return xa_to_value(xa_load(>mem_attr_array, gfn));
}
--
Kiryl Shutsemau / Kirill A. Shutemov
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
tmap 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
estricted 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 potenti
if there's any?
--
Kiryl Shutsemau / Kirill A. Shutemov
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_op = _iops;
> > + inode->i_mapping->private_data = data;
> > +
> > + file = alloc_file_pseudo(inode, inaccessible_mnt,
> > +"[memfd:inaccessible]", O_RDWR,
> > +_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
if it is now inaccessible. It should be trivial by
checking file->f_inode->i_sb->s_magic.
--
Kiryl Shutsemau / Kirill A. Shutemov
struct inaccessible_notifier *notifier)
> > +{
> > + struct inaccessible_data *data = file->f_mapping->private_data;
> > +
> > + mutex_lock(>lock);
> > + list_add(>list, >notifiers);
> > + mutex_unlock(>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
>
r 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
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
lidate_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:
> > &g
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, than
cesses 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
_head(page));
+ return 0;
+}
+EXPORT_SYMBOL_GPL(inaccessible_get_pfn);
+
+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(>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
&
cked until it lends into SEPT and
must make it dirty before unlocking.
--
Kiryl Shutsemau / Kirill A. Shutemov
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
ranges 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
> 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). Howe
te(>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 in
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 by that. tl
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
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
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-off-by: Kir
Looks like this patchset got stuck and never reached upsteam.
Any update on this?
--
Kirill A. Shutemov
s fix this by teaching mux to send an event to the frontend with
> the focus.
>
> Reported-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com>
> Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
> Fixes: a4afa548fc6d ("char: move front end handlers i
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 <kirill.shute...@linux.intel.com>
Fixes: a4afa548fc6d
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 <kirill.shute...@linux.intel.com>
---
target-i386/arch_memory_mapping.c | 42 ++-
target-i386/cpu.c | 16 ++-
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 <kirill.shute...@linux.intel.com>
Cc: qemu-devel@nongnu.org
---
target-i386/arch_memory_mapping.c | 42 --
target-i386/cpu.c
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(
ic, doesn't it?
> +static inline int PageTransCompoundMap(struct page *page)
> +{
> + return PageTransCompound(page) && atomic_read(>_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
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
.
*/
- [0 ... (BITS_PER_LONG-1)] = ??,
+ [0 ... (BITS_PER_LONG)] = ??,
[ilog2(VM_READ)]= rd,
[ilog2(VM_WRITE)] = wr,
--
Kirill A. Shutemov
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, mprotect().
--
Kirill
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
vma flags. Whenever
limitation on
pages' mapcount? The limitation looks artificial from interface POV.
--
Kirill A. Shutemov
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:
On Fri, Oct 03, 2014 at 07:07:58PM +0200
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 set VM_USERFAULT in the
vma
and cleanup code a bit.
Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
Reviewed-by: Daniel P. Berrange berra...@redhat.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/9pfs/cofile.c | 4
hw/9pfs/virtio-9p-handle.c | 8 +++-
hw/9pfs/virtio-9p
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 in st_result_mask. It may mislead client
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 kirill.shute...@linux.intel.com
---
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
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 kirill.shute...@linux.intel.com
---
hw/9pfs/virtio-9p-handle.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/9pfs
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 kirill.shute...@linux.intel.com
---
hw/9pfs/cofile.c| 4
hw/9pfs/virtio-9p.c | 12 ++--
2 files changed, 10 insertions(+), 6
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 kirill.shute...@linux.intel.com
Aneesh Kumar K.V wrote:
Kirill A. Shutemov kirill.shute...@linux.intel.com 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
still set P9_STATS_GEN bit in st_result_mask
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.
- If we failed to get valid
and cleanup code a bit.
Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
Reviewed-by: Daniel P. Berrange berra...@redhat.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
hw/9pfs/cofile.c | 4
hw/9pfs/virtio-9p-handle.c | 8 +++-
hw/9pfs/virtio-9p
On Wed, Nov 06, 2013 at 09:41:47PM +0530, Aneesh Kumar K.V wrote:
Kirill A. Shutemov kir...@shutemov.name writes:
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
Currently we have few issues with P9_STATS_GEN:
- We don't try to read st_gen anything except files
From: Kirill A. Shutemov kirill.shute...@linux.intel.com
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
On Sun, Oct 27, 2013 at 03:41:34AM +0300, Kirill A. Shutemov wrote:
From: Kirill A. Shutemov kir...@shutemov.name
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
From: Kirill A. Shutemov kir...@shutemov.name
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
and cleanup code a bit.
Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com
---
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
On Wed, Jan 20, 2010 at 12:33 PM, Daniel P. Berrange
berra...@redhat.com 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 quint...@redhat.com wrote:
From: Kirill A. Shutemov kir...@shutemov.name
CC block/vvfat.o
On Wed, Jan 20, 2010 at 2:15 PM, Markus Armbruster arm...@redhat.com wrote:
Kevin Wolf kw...@redhat.com writes:
Am 20.01.2010 12:09, schrieb Kirill A. Shutemov:
On Wed, Jan 20, 2010 at 12:33 PM, Daniel P. Berrange
berra...@redhat.com wrote:
On Wed, Jan 20, 2010 at 08:19:26AM +0200, Kirill
On Wed, Jan 20, 2010 at 3:03 PM, Markus Armbruster arm...@redhat.com wrote:
Kirill A. Shutemov kir...@shutemov.name 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 you provide
2010/1/20 Gleb Natapov g...@redhat.com:
On Wed, Jan 20, 2010 at 02:03:04PM +0100, Markus Armbruster wrote:
Kirill A. Shutemov kir...@shutemov.name writes:
No, compiler can't add anything between. 'char' is always byte-aligned.
You got some reading to do then.
To be fair this structure
On Tue, Jan 19, 2010 at 2:11 PM, Juan Quintela quint...@redhat.com wrote:
Kirill A. Shutemov kir...@shutemov.name wrote:
A variant of write(2) which handles partial write.
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
Hi
Have you updated this series? Is there any reason that you
On Wed, Jan 20, 2010 at 1:56 AM, Juan Quintela quint...@redhat.com wrote:
From: Kirill A. Shutemov kir...@shutemov.name
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 'ftruncate
On Tue, Jan 5, 2010 at 4:42 PM, Juan Quintela quint...@trasno.org wrote:
Kirill A. Shutemov kir...@shutemov.name 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 return value of 'fgets', declared
On Thu, Dec 31, 2009 at 12:58 PM, Arnaud Patard
arnaud.pat...@rtp-net.org wrote:
Kirill A. Shutemov kir...@shutemov.name writes:
Hi,
-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
On Thu, Dec 31, 2009 at 12:50 PM, Arnaud Patard
arnaud.pat...@rtp-net.org wrote:
Kirill A. Shutemov kir...@shutemov.name writes:
Hi,
CC i386-linux-user/mmap.o
cc1: warnings being treated as errors
/usr/src/RPM/BUILD/qemu-0.11.92/linux-user/mmap.c: In function 'mmap_frag':
/usr/src/RPM
A variant of write(2) which handles partial write.
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
osdep.c | 27 +++
qemu-common.h |2 ++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/osdep.c b/osdep.c
index e4836e7..8ae48fe 100644
CCposix-aio-compat.o
cc1: warnings being treated as errors
posix-aio-compat.c: In function 'aio_signal_handler':
posix-aio-compat.c:505: error: ignoring return value of 'write', declared with
attribute warn_unused_result
make: *** [posix-aio-compat.o] Error 1
Signed-off-by: Kirill
warn_unused_result
make: *** [block/cow.o] Error 1
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
block/cow.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/block/cow.c b/block/cow.c
index a70854e..ba07b97 100644
--- a/block/cow.c
+++ b/block/cow.c
warn_unused_result
block/qcow.c:811: error: ignoring return value of 'write', declared with
attribute warn_unused_result
make: *** [block/qcow.o] Error 1
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
block/qcow.c | 25 +
1 files changed, 21 insertions(+), 4 deletions
/vmdk.o] Error 1
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
block/vmdk.c | 50 --
1 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 4e48622..58fc04b 100644
--- a/block/vmdk.c
+++ b/block
to __builtin___snprintf_chk will
always overflow destination buffer
make: *** [block/vvfat.o] Error 1
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
block/vvfat.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 063f731..8140dbc 100644
', declared with
attribute warn_unused_result
make: *** [block/qcow2.o] Error 1
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
block/qcow2.c | 55 +--
1 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/block/qcow2.c b/block
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 kir...@shutemov.name
1 - 100 of 208 matches
Mail list logo
