st insert the thing.. */
> folio_get(folio);
> + if (mkwrite)
> + entry = maybe_mkwrite(mk_pte(page, prot), vma);
> + else
> + entry = mk_pte(page, prot);
I'd prefer:
entry = mk_pte(page, prot);
if (mkwrite)
entry = maybe_mkwrite(entry, vma);
but I don't insist. Also insert_pfn() additionally has pte_mkyoung() and
pte_mkdirty(). Why was it left out here?
Honza
--
Jan Kara
SUSE Labs, CR
static int path_removexattr(const char __user
> *pathname,
> return error;
> }
>
> +SYSCALL_DEFINE4(removexattrat, int, dfd, const char __user *, pathname,
> + const char __user *, name, int, flags)
> +{
Same comment as above - "flags" -> "at_flags" and reorder args please.
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 05-12-23 21:22:59, Yury Norov wrote:
> On Mon, Dec 04, 2023 at 07:51:01PM +0100, Jan Kara wrote:
> > > This series is a result of discussion [1]. All find_bit() functions imply
> > > exclusive access to the bitmaps. However, KCSAN reports quite a number
> > > o
o atomic find_and_bit() as appropriate.
Well, all users where any concurrency can happen should switch. Otherwise
they are prone to the (admittedly mostly theoretical) data race issue.
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 22-11-23 13:48:25, Christian Brauner wrote:
> No caller care about the return value.
>
> Signed-off-by: Christian Brauner
Yup. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/eventfd.c
to add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/eventfd.c| 7 ---
> include/linux/eventfd.h | 5 ++---
> io_uring/io_uring.c | 4 ++--
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
>
ng that additional argument.
>
> Signed-off-by: Christian Brauner
Looks good. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> arch/x86/kvm/hyperv.c | 2 +-
> arch/x86/kvm/xen.c
On Wed 22-11-23 13:48:22, Christian Brauner wrote:
> The single caller of inject_virtual_interrupt() ignores the return value
> anyway. This allows us to simplify eventfd_signal() in follow-up
> patches.
>
> Signed-off-by: Christian Brauner
Looks good. Feel free to add:
Review
n defconfigs. But sure if
m68k or other arch wants to keep reiserfs in it's defconfig for some
consistency reasons, I'm fine with it. I just suspect that for most archs
this is just a historical reason.
Honza
--
Jan Kara
SUSE Labs, CR
On Wed 05-07-23 14:58:12, Jeff Layton wrote:
> Now that everything in-tree is converted to use the accessor functions,
> rename the i_ctime field in the inode to discourage direct access.
>
> Signed-off-by: Jeff Layton
Looks good. Feel free to add:
Reviewed-
struct inode *, struct dentry *);
> extern int simple_unlink(struct inode *, struct dentry *);
> extern int simple_rmdir(struct inode *, struct dentry *);
> +void simple_rename_timestamp(struct inode *old_dir, struct dentry
> *old_dentry,
> + struct inode *new_dir, struct dentry *new_dentry);
> extern int simple_rename_exchange(struct inode *old_dir, struct dentry
> *old_dentry,
> struct inode *new_dir, struct dentry
> *new_dentry);
> extern int simple_rename(struct mnt_idmap *, struct inode *,
> --
> 2.41.0
>
--
Jan Kara
SUSE Labs, CR
er to do that safely though, we'll need to eradicate raw
> accesses of the inode->i_ctime field from the kernel.
>
> Add new accessor functions for the ctime that we can use to replace them.
>
> Signed-off-by: Jeff Layton
Looks good to m
gt; inode->i_uid = current_fsuid();
> inode->i_gid = current_fsgid();
> - inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);
> + inode->i_atime = inode->i_mtime = inode_ctime_set_current(inode);
> out:
> return inode;
> }
> --
> 2.41.0
>
--
Jan Kara
SUSE Labs, CR
sumably we didn't want to use modulo here because EXT4_MMP_SEQ_MAX
is rather big and so the resulting 'new_seq' would be seriously
non-uniform.
Honza
--
Jan Kara
SUSE Labs, CR
sctl-subdir-register-sysctl-simplify.cocci PATH
Heh, nice example of using Coccinelle. The result looks good. Feel free to
add:
Reviewed-by: Jan Kara
Honza
>
> @c1@
> expression E1;
> identifier subdir, sysctls;
> @@
roc_handler = proc_dointvec,
> },
> #endif
> -#ifdef CONFIG_INOTIFY_USER
> - {
> - .procname = "inotify",
> - .mode = 0555,
> - .child = inotify_table,
> - },
> -#endif
> -#ifdef CONFIG_FANOTIFY
> - {
> - .procname = "fanotify",
> - .mode = 0555,
> - .child = fanotify_table,
> - },
> -#endif
> #ifdef CONFIG_EPOLL
> {
> .procname = "epoll",
> --
> 2.33.0
>
--
Jan Kara
SUSE Labs, CR
4ba3fcdde7e3 ("jbd2,ext4: add a shrinker to release checkpointed
> buffers")
> Reported-by: Sachin Sant
> Reported-by: Jon Hunter
> Signed-off-by: Theodore Ts'o
Except for the bug Zhang Yi noticed the patch looks good to me. Feel free
to add:
Reviewed-by: Jan Kara
afte
On Tue 02-06-20 17:59:08, Williams, Dan J wrote:
> [ forgive formatting, a series of unfortunate events has me using Outlook for
> the moment ]
>
> > From: Jan Kara
> > > > > These flags are device properties that affect the kernel and
> > >
On Mon 01-06-20 17:31:50, Aneesh Kumar K.V wrote:
> On 6/1/20 3:39 PM, Jan Kara wrote:
> > On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
> > > On 5/29/20 3:22 PM, Jan Kara wrote:
> > > > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> > > > > Th
On Fri 29-05-20 16:25:35, Aneesh Kumar K.V wrote:
> On 5/29/20 3:22 PM, Jan Kara wrote:
> > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> > > Thanks Michal. I also missed Jeff in this email thread.
> >
> > And I think you'll also need some of the sched
On Sat 30-05-20 09:35:19, Dan Williams wrote:
> On Sat, May 30, 2020 at 12:18 AM Aneesh Kumar K.V
> wrote:
> >
> > On 5/30/20 12:52 AM, Dan Williams wrote:
> > > On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V
> > > wrote:
> > >>
>
t; > > +unsigned long default_map_sync_mask = 0;
> > > +#endif
> > > +
I'm not sure CONFIG is really the right approach here. For a distro that would
basically mean to disable MAP_SYNC for all PPC kernels unless application
explicitly uses the right prctl. Shouldn't we ra
ches.
>
>If that's too much trouble, then I'd have to fall back to submitting a few
>patches at a time and working my way up to the tracking patch...
It could also be that an ordinary page reference is dropped with 'unpin'
thus underflowing the page refcount...
Honza
--
Jan Kara
SUSE Labs, CR
On Fri 20-12-19 16:06:05, Alexey Kardashevskiy wrote:
>
>
> On 11/12/2019 21:42, Jan Kara wrote:
> > The last jump to free_exit in mm_iommu_do_alloc() happens after page
> > pointers in struct mm_iommu_table_group_mem_t were already converted to
> > physical addresses.
st would work... And I don't think
making all GUP users huge page aware is realistic (effort-wise) or even
wanted (maintenance overhead in all those places).
I believe there might be also a different solution for this: For
transparent huge pages, we could find a space in 'struct page' of the
second page in the huge page for proper pin counter and just account pins
there so we'd have full width of 32-bits for it.
Honza
--
Jan Kara
SUSE Labs, CR
er testing exposure and is
prepared for the next merge window.
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 16-12-19 14:18:59, John Hubbard wrote:
> On 12/16/19 4:53 AM, Jan Kara wrote:
> > With this fixed, the patch looks good to me so you can then add:
> >
> > Reviewed-by: Jan Kara
> >
> > Ho
d get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
>
> Suggested-by: Jan Kara
> Suggested-by: Jérôme Glisse
> Cc: Kirill A. Shutemov
> Signed-off-b
d get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
>
> Suggested-by: Jan Kara
> Suggested-by: Jérôme Glisse
> Cc: Kirill A. Shutemov
> Signed-off-by: J
d get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
The patch looks mostly good to me now. Just a few smaller comments below.
> Suggested-by: Jan Kara
> Suggested-by
On Tue 10-12-19 18:53:13, John Hubbard wrote:
> 1. Convert from get_user_pages() to pin_user_pages().
>
> 2. As required by pin_user_pages(), release these pages via
> put_user_page().
>
> Cc: Jan Kara
> Signed-off-by: John Hubbard
The patch looks good to me. You can a
cleanup.
Signed-off-by: Jan Kara
---
arch/powerpc/mm/book3s64/iommu_api.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Beware, this is completely untested, spotted just by code audit.
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
b/arch/powerpc/mm/book3s64/iommu_api.c
index
d get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
>
> Suggested-by: Jan Kara
> Suggested-by: Jérôme Glisse
> Signed-off-by: John Hubbard
Looks nice,
into the patch the uses
> the gup flags arguments.
You should probably implement this TODO? :)
Honza
>
> Reviewed-by: Jan Kara
> Reviewed-by: Jérôme Glisse
> Reviewed-by: Ira Weiny
> Cc: Kirill A. Shu
RN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM)))
> + if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
> + FOLL_FORCE)))
> return -EINVAL;
>
> start = untagged_addr(start) & PAGE_MASK;
> --
> 2.24.0
>
--
Jan Kara
SUSE Labs, CR
before the video HW
stored data in the page) and the page then gets evicted from the page cache.
Honza
--
Jan Kara
SUSE Labs, CR
ere we have reference on the inode it
> hangs off." [1]
>
> [1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
>
> Cc: Jan Kara
> Signed-off-by: John Hubbard
> ---
> arch/powerpc/mm/book3s64/iommu_api.c | 12 +---
> 1 file changed, 5 insertions(+
rty(page);
> + put_user_pages_dirty_lock(&mem->hpages[i], 1,
> + MM_IOMMU_TABLE_GROUP_PAGE_DIRTY);
And the dirtying condition is wrong here as well. Currently it is always
true.
Honza
--
Jan Kara
SUSE Labs, CR
On Thu 21-11-19 18:54:02, John Hubbard wrote:
> On 11/21/19 1:54 AM, Jan Kara wrote:
> > On Thu 21-11-19 00:29:59, John Hubbard wrote:
> > > >
> > > > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > > > Andrew
with), it would probably make sense to push also the
put_user_pages() -> unpin_user_pages() renaming so that that inconsistency
in naming does not exist in the released upstream kernel.
Honza
--
Jan Kara
SUSE Labs, CR
them as we do now because
ideally in 4 weeks we should have them ready with all the reviews so that
they can be picked up and integrated into linux-next.
Honza
--
Jan Kara
SUSE Labs, CR
ser_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/
>
> Suggested-by: Jan Kara
> Suggested-by: Jérôme Glisse
> Signed-off-by: Jo
igned-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> Documentation/core-api/pin_user_pages.rst | 2 +-
> arch/powerpc/mm/book3s64/iommu_api.c| 6 +--
> drivers/gpu/drm/vi
'd add a helper grab_page(page,
flags) doing
if (flags & FOLL_GET)
get_page(page);
else if (flags & FOLL_PIN)
return try_pin_page(page);
return true;
Otherwise the patch looks good to me now.
Honza
--
Jan Kara
SUSE Labs, CR
surrounded
> by get_page()/put_page().
>
> Also, further simplify (slightly), by waiting until the the successful
> end of each routine, to increment *nr.
>
> Reviewed-by: Jérôme Glisse
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Christoph Hellwig
> Cc: Aneesh Kumar K.V
153640.gb...@lst.de
>
> Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/platform/goldfish/goldfish_pipe.c | 17 +++-
user_pages() to pin_user_pages().
>
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> fs/io_uring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
: Jérôme Glisse
> Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/platform/goldfish/goldfish_pipe.c | 18 +-
> 1 file ch
> 1 file changed, 15 insertions(+), 13 deletions(-)
The patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
ere usages which are transient.
^^^ when you touch this, please fix also the
second sentense. It doesn't quite make sense to me... I'd probably write
there "whose usages are transient" but maybe you can come up with something
even better.
Otherwise the patch looks good
ewed-by: Ira Weiny
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/infiniband/core/umem.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletion
surrounded
> by get_page()/put_page().
>
> Also, further simplify (slightly), by waiting until the the successful
> end of each routine, to increment *nr.
>
> Reviewed-by: Jérôme Glisse
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Christoph Hellwig
> Cc: Aneesh
is left to later
> patchsets. There is discussion about this in [1].
^^ missing this reference
in the changelog...
> This also changes a BUG_ON(), to a WARN_ON(), in follow_page_mask().
>
> Suggested-by: Jan Kara
> Suggested-by: Jé
> + SetPageReferenced(head);
> +}
I don't find this last helper very useful. It seems to muddy water more
than necessary...
Other than that the cleanup looks nice to me.
Honza
--
Jan Kara
SUSE Labs, CR
ewed-by: Ira Weiny
> Cc: Kirill A. Shutemov
> Signed-off-by: John Hubbard
Looks good! You can add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/gup.c | 28 ++--
> 1 file changed, 18 insertions(+
On Tue 12-11-19 20:26:50, John Hubbard wrote:
> An upcoming patch uses try_get_compound_head() more widely,
> so move it to the top of gup.c.
>
> Also fix a tiny spelling error and a checkpatch.pl warning.
>
> Signed-off-by: John Hubbard
Looks good. You can add:
Rev
periments.
> Since then, Jérôme Glisse suggested the refactoring described above.
>
> Suggested-by: Jérôme Glisse
> Signed-off-by: Ira Weiny
> Signed-off-by: John Hubbard
Looks good to me. You can add:
Reviewed-by: Jan Kara
cs, should call a
> get_user_pages()-like wrapper call that sets FOLL_PIN. These wrappers
> will:
> * Start with "pin_user_pages" instead of "get_user_pages". That
> makes it easy to find and audit the call sites.
> * Set FOLL_PIN
>
hy I started off with a proposal that avoids changing the
> names of put_user_page*() APIs). But OTOH, the amount of churn is proportional
> to the change in direction here, and it's really only 10 or 20 lines changed,
> in the end.
>
> So I'm open to changing to that naming. It would be nice to hear what others
> prefer, too...
FWIW I'd find unpin_user_page() also better than put_user_page() as a
counterpart to pin_user_pages().
Honza
--
Jan Kara
SUSE Labs, CR
On Mon 14-10-19 08:23:39, Eric Sandeen wrote:
> On 10/14/19 4:43 AM, Jan Kara wrote:
> > On Mon 14-10-19 16:33:15, Pingfan Liu wrote:
> > > On Sun, Oct 13, 2019 at 09:34:17AM -0700, Darrick J. Wong wrote:
> > > > On Sun, Oct 13, 2019 at 10:37:00PM +0800, Pingfan L
s' implementation. What
> about introducing an interface sync_to_fsblock(struct super_block *sb) in
> the struct super_operations, then let each fs manage its own case?
Well, we already have a way to achieve what you need: fsfreeze.
Traditionally, that is guaranteed to put fs into a "clean" state very much
equivalent to the fs being unmounted and that seems to be what the
bootloader wants so that it can access the filesystem without worrying
about some recovery details. So do you see any problem with replacing
'sync' in your example above with 'fsfreeze /boot && fsfreeze -u /boot'?
Honza
--
Jan Kara
SUSE Labs, CR
hat's a good thing as upgrading kernels is
going to be nightmare due to this on PPC64. So I believe we should make
defaults for old superblocks such that working setups keep working without
sysadmin having to touch anything.
Honza
--
Jan Kara
SUSE Labs, CR
re #defines to
> mman-common.h. That can be done as a separate patch.
>
> Signed-off-by: Aneesh Kumar K.V
Looks good to me FWIW (I don't have much experience with mmap flags and
their peculirarities). So feel free to add:
Reviewed-by: Jan Kara
On Thu 25-04-19 17:33:04, Dan Williams wrote:
> On Thu, Apr 25, 2019 at 12:32 AM Jan Kara wrote:
> >
> > On Wed 24-04-19 11:13:48, Dan Williams wrote:
> > > On Wed, Apr 24, 2019 at 10:38 AM Matthew Wilcox
> > > wrote:
> > > >
> > > > On
in dax_insert_pfn_mkwrite() -- does
> > that need to change too?
>
> It wasn't clear to me that it was a problem. I think that one already
> happens to be pmd-aligned.
Why would it need to be? The address is taken from vmf->address and that's
set up in __handle_mm_fault() like .address = address & PAGE_MASK. So I
don't see anything forcing PMD alignment of the virtual address...
Honza
--
Jan Kara
SUSE Labs, CR
ithout this patch we also see the below message in kernel log
> "BUG: non-zero pgtables_bytes on freeing mm:"
>
> CC: sta...@vger.kernel.org
> Reported-by: Chandan Rajendra
> Signed-off-by: Aneesh Kumar K.V
Looks good to me. You can add:
Reviewed-by: Jan Kara
CC: sta...@vger.kernel.org
> Signed-off-by: Aneesh Kumar K.V
Thanks for fixing this! The patch looks good to me. Feel free to add:
Reviewed-by: Jan Kara
Honza
> ---
> mm/huge_memory.c | 31 ++
mem_copy_from_iter+0x2c/0x50 [nd_pmem]
> > dax_copy_from_iter+0x40/0x70
> > dax_iomap_actor+0x134/0x360
> > iomap_apply+0xfc/0x1b0
> > dax_iomap_rw+0xac/0x130
> > ext4_file_write_iter+0x254/0x460 [ext4]
> > __vfs_write+0x120/0x1e0
> > vfs_write+0xd8/0x220
&
&transparent_hugepage_flags);
> ret = 1;
> }
> out:
> @@ -753,6 +756,7 @@ static void insert_pfn_pmd(struct vm_area_struct *vma,
> unsigned long addr,
> spinlock_t *ptl;
>
> ptl = pmd_lock(mm, pmd);
> + /* should we check for none here again? */
> entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
> if (pfn_t_devmap(pfn))
> entry = pmd_mkdevmap(entry);
> --
> 2.20.1
>
--
Jan Kara
SUSE Labs, CR
; ext4_file_write_iter+0x254/0x460 [ext4]
> __vfs_write+0x120/0x1e0
> vfs_write+0xd8/0x220
> SyS_write+0x6c/0x110
> system_call+0x3c/0x130
>
> Signed-off-by: Aneesh Kumar K.V
Thanks for the patch. It looks good to me. You can add:
Reviewed-by: Jan Kara
> ---
>
_do_munmap+0x2f0/0x510
>.__vm_munmap+0x80/0x110
>.__se_sys_munmap+0x14/0x30
>system_call+0x5c/0x70
>
> The fix is simple, we need to convert the result of the bitwise && to
> an int before returning it.
>
> Thanks to Jan Kara and Aneesh for help with debu
ge so that it can be used for reproduction. Thanks!
Honza
--
Jan Kara
SUSE Labs, CR
is a straightforward conversion from calling
> filemap_write_and_wait_range in their fsync operation to calling
> file_write_and_wait_range.
>
> Signed-off-by: Jeff Layton
This all looks rather obvious. Feel free to add:
Acked-by: Jan Kara
ter
Signed-off-by: Jan Kara
---
arch/powerpc/sysdev/axonram.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Warning: The patch is not tested in any way. I just based the fix on Smatch
warning and how things should be...
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sys
to compute the
> number of blocks to be cleaned.
Ah, good catch. You can add:
Reviewed-by: Jan Kara
Honza
> Signed-off-by: Chandan Rajendra
> ---
> fs/direct-io.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 delet
addr, buf, len, write);
> + return __access_remote_vm(NULL, mm, addr, buf, len,
> + write ? FOLL_WRITE : 0);
> }
>
> /*
> @@ -1871,7 +1873,8 @@ int access_process_vm(struct task_struct *tsk, unsigned
> long addr, void *buf, in
> if (!mm)
> return 0;
>
> - len = __access_remote_vm(tsk, mm, addr, buf, len, write);
> + len = __access_remote_vm(tsk, mm, addr, buf, len,
> + write ? FOLL_WRITE : 0);
>
> mmput(mm);
> return len;
> --
> 2.10.0
>
--
Jan Kara
SUSE Labs, CR
r
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 7 +--
> drivers/g
hence
> bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
The patch looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> arch/cris/arch-v32/drivers/cryptocop.c |
r (and hence
> bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c| 3 ++-
> drivers/media/pla
r
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
After our discussion the patch looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
On Tue 18-10-16 14:56:09, Lorenzo Stoakes wrote:
> On Tue, Oct 18, 2016 at 02:54:25PM +0200, Jan Kara wrote:
> > > @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned
> > > long nr_pages,
> > > int write,
s second but I don't care that much. But it definitely should be
consistent...
Honza
--
Jan Kara
SUSE Labs, CR
iour
> (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
> mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
The patch looks good. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
he mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes
Looks good. You can add:
Reviewed-by: Jan Kara
Honza
--
Jan Kara
SUSE Labs, CR
1 trap = 300
> dar = c00039d0 dsisr = 4000
> 0:mon>
Yes, this makes me even more suspitious that memcpy() on powerpc could
be at fault. The instruction (ld r9,8(r4)) is loading last 8 bytes to copy,
but in fact it should load only 3 bytes in our case becaus
Hello,
On Tue 24-02-09 12:08:37, Sachin P. Sant wrote:
> Jan Kara wrote:
>> Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
>> somehow got beyond end of the page referenced by bh->b_data. So it means
>> that le16_to_cpu(entry->e_val
f). As far as I can
remember powerpc monitor could dump it.
BTW, I suppose you use 4KB blocksize on the filesystem, right?
Honza
--
Jan Kara
SuSE CR Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ode_child(dentry->d_name.name, dentry, inode);
> >> 111 }
> >> 112
> >>
> >
> > If it is reproducible can you please try reverting
> > inotify-send-in_attrib-events-when-link-count-changes.patch?
>
> Hi Andrew,
>
> reverting the patch
dentry->d_inode);
> >> 110 audit_inode_child(dentry->d_name.name, dentry, inode);
> >> 111 }
> >> 112
> >>
> >
> > If it is reproducible can you please try reverting
> > inotify-send-in_attrib-events-when-link-count-changes.patch?
>
> Hi Andrew,
>
> reverting the patch
> inotify-send-in_attrib-events-when-link-count-changes.patch, the
> bug is not reproduced.
OK, thanks for testing. I was trying to reproduce the problem locally but
without success so far - I guess it's either NFS or CIFS which makes the
problem appear. I'll investigate more.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
90 matches
Mail list logo