search for: f_ops

Hi everyone, The Linux Coda drivers and the ext3 patches don't seem to get along very well, at least in Linux 2.4.7. I've got a stock 2.4.7 kernel with a patch applied to the USB drivers (for a sony digital camera; see http://www.sujal.net/tech/linux/ just a change in unusual_devs.h). After I applied the ext3 patches from http://www.uow.edu.au/~andrewm/linux/ext3/ . Basically,

Hello, I see a reproducable panic when doing ibping and aborting it with ^C. My setup is two machines with Mellanox Infinihost III HCAs (one Linux one FreeBSD) connected back-to-back. Details below. I can upload 2 crash dumps, if this is useful. For some reason the port doesn't become ACTIVE, so no packets arrive, but that is probably unrelated. % uname -a FreeBSD cosel.inf.tu-dresden.de

Hey, We are blocked on a bug fixed by RHEL in https://rhn.redhat.com/errata/RHBA-2012-0362.html. Specifically, the splice code in sendfile() incorrectly updating the offset position on the write side, Red Hat BZ#771868. I have not been able to figure out if this bugfix is included in any CentOS releases. If you are better at reading release notes than me, could you please help me out and let me

...t;>>>> Could you share your usecase? >>>> >>>> Sure. >>> >>> Thanks a lot! >>> >>>> >>>> My driver has privately managed non LRU pages which gets mapped into user space >>>> process page table through f_ops->mmap() and vmops->fault() which then updates >>>> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing >>> >>> Hmm, page_add_file_rmap is not exported function. How does your driver can use it? >> >> Its not using t...

...t;>>>> Could you share your usecase? >>>> >>>> Sure. >>> >>> Thanks a lot! >>> >>>> >>>> My driver has privately managed non LRU pages which gets mapped into user space >>>> process page table through f_ops->mmap() and vmops->fault() which then updates >>>> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing >>> >>> Hmm, page_add_file_rmap is not exported function. How does your driver can use it? >> >> Its not using t...

...;>> >>>>>> Sure. >>>>> >>>>> Thanks a lot! >>>>> >>>>>> >>>>>> My driver has privately managed non LRU pages which gets mapped into user space >>>>>> process page table through f_ops->mmap() and vmops->fault() which then updates >>>>>> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing >>>>> >>>>> Hmm, page_add_file_rmap is not exported function. How does your driver can use it? >>&...

...;>> >>>>>> Sure. >>>>> >>>>> Thanks a lot! >>>>> >>>>>> >>>>>> My driver has privately managed non LRU pages which gets mapped into user space >>>>>> process page table through f_ops->mmap() and vmops->fault() which then updates >>>>>> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing >>>>> >>>>> Hmm, page_add_file_rmap is not exported function. How does your driver can use it? >>&...

...usecase? > >>>> > >>>> Sure. > >>> > >>> Thanks a lot! > >>> > >>>> > >>>> My driver has privately managed non LRU pages which gets mapped into user space > >>>> process page table through f_ops->mmap() and vmops->fault() which then updates > >>>> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing > >>> > >>> Hmm, page_add_file_rmap is not exported function. How does your driver can use it? > >> >...

On 01/12/14 20:33, Jeff Hammerbacher wrote: > Hey, > > We are blocked on a bug fixed by RHEL in > https://rhn.redhat.com/errata/RHBA-2012-0362.html. Specifically, the splice > code in sendfile() incorrectly updating the offset position on the write > side, Red Hat BZ#771868. > > I have not been able to figure out if this bugfix is included in any CentOS > releases. If

...t; PTE steps. > You're right. Unfortunately, it doesn't support right now but surely, > it's my TODO after landing this work. > > Could you share your usecase? Sure. My driver has privately managed non LRU pages which gets mapped into user space process page table through f_ops->mmap() and vmops->fault() which then updates the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing to note here is that the page->mapping eventually points to struct address_space (file->f_mapping) which belongs to the character device file (created us...

...t; PTE steps. > You're right. Unfortunately, it doesn't support right now but surely, > it's my TODO after landing this work. > > Could you share your usecase? Sure. My driver has privately managed non LRU pages which gets mapped into user space process page table through f_ops->mmap() and vmops->fault() which then updates the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing to note here is that the page->mapping eventually points to struct address_space (file->f_mapping) which belongs to the character device file (created us...

...>>> it's my TODO after landing this work. >>> >>> Could you share your usecase? >> >> Sure. > > Thanks a lot! > >> >> My driver has privately managed non LRU pages which gets mapped into user space >> process page table through f_ops->mmap() and vmops->fault() which then updates >> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing > > Hmm, page_add_file_rmap is not exported function. How does your driver can use it? Its not using the function directly, I just re-iterated...

...>>> it's my TODO after landing this work. >>> >>> Could you share your usecase? >> >> Sure. > > Thanks a lot! > >> >> My driver has privately managed non LRU pages which gets mapped into user space >> process page table through f_ops->mmap() and vmops->fault() which then updates >> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing > > Hmm, page_add_file_rmap is not exported function. How does your driver can use it? Its not using the function directly, I just re-iterated...

After commit 2b8b328b61c799957a456a5a8dab8cc7dea68575 (vhost_net: handle polling errors when setting backend), we in fact track the polling state through poll->wqh, so there's no need to duplicate the work with an extra vhost_net_polling_state. So this patch removes this and make the code simpler. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 60

After commit 2b8b328b61c799957a456a5a8dab8cc7dea68575 (vhost_net: handle polling errors when setting backend), we in fact track the polling state through poll->wqh, so there's no need to duplicate the work with an extra vhost_net_polling_state. So this patch removes this and make the code simpler. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 60

Hi, A system running ext3 crashed this afternoon (nothing to do with ext3, bad network driver). Is was saving a file from emacs when it happened. The file system is 0.06b and had ordered data as the mount option. Let me emphasize this was running ext3 pure, not with SnapFS or InterMezzo layered on top of it. strace reveals that Emacs does open("existing file name", O_TRUNC |

After commit 2b8b328b61c799957a456a5a8dab8cc7dea68575 (vhost_net: handle polling errors when setting backend), we in fact track the polling state through poll->wqh, so there's no need to duplicate the work with an extra vhost_net_polling_state. So this patch removes this and make the code simpler. This patch also removes the all tx starting/stopping code in tx path according to

After commit 2b8b328b61c799957a456a5a8dab8cc7dea68575 (vhost_net: handle polling errors when setting backend), we in fact track the polling state through poll->wqh, so there's no need to duplicate the work with an extra vhost_net_polling_state. So this patch removes this and make the code simpler. This patch also removes the all tx starting/stopping code in tx path according to

...ork. > >>> > >>> Could you share your usecase? > >> > >> Sure. > > > > Thanks a lot! > > > >> > >> My driver has privately managed non LRU pages which gets mapped into user space > >> process page table through f_ops->mmap() and vmops->fault() which then updates > >> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing > > > > Hmm, page_add_file_rmap is not exported function. How does your driver can use it? > > Its not using the function dir...

These mappings are in fact special and require special handling in privcmd, which already exists. Failure to mark the PTE as special on arm64 causes all sorts of bad PTE fun. x86 already gets this correct. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: xen-devel@lists.xenproject.org --- arch/arm/xen/enlighten.c |