Re: BUG: unable to handle kernel paging request in dqput

2020-09-29 Thread Jan Kara
he Oops code path. > It must be a different reason. Yeah, it seems the bisection got confused because it hit a different error during the bisection. Looking at the original oops, I think the actual reason of a crash is that quota file got corrupted in a particular way. Quota code is not very

Re: [PATCH] proc: Use new_inode not new_inode_pseudo

2020-06-15 Thread Jan Kara
ot;) > Fixes: 021ada7dff22 ("procfs: switch /proc/self away from proc_dir_entry") > Fixes: 51f0885e5415 ("vfs,proc: guarantee unique inodes in /proc") > Signed-off-by: "Eric W. Biederman" Thanks for analysing this! I agree with the analysis and the patch look

Re: [PATCH v2 1/2] docs: mm/gup: pin_user_pages.rst: add a "case 5"

2020-06-01 Thread Jan Kara
rivers/vhost/vhost.c > has a "pin, write to page, set page dirty, unpin" case. > > Add a fifth case, to help explain that there is a general pattern > that requires pin_user_pages*() API calls. > > Cc: Vlastimil Babka > Cc: Jan Kara > Cc: Jérôme Glisse > Cc:

Re: [PATCH 2/2] vhost: convert get_user_pages() --> pin_user_pages()

2020-06-01 Thread Jan Kara
_user_pages.rst > > [2] "Explicit pinning of user-space pages": > https://lwn.net/Articles/807108/ > > Cc: Michael S. Tsirkin > Cc: Jason Wang > Cc: k...@vger.kernel.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: netdev@vger.kernel.or

Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

2020-05-07 Thread Jan Kara
On Wed 06-05-20 21:38:40, Souptick Joarder wrote: > On Wed, May 6, 2020 at 6:29 PM Jan Kara wrote: > > > > On Wed 06-05-20 17:51:39, Souptick Joarder wrote: > > > On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote: > > > > > > > > On Wed 06-05-20 02

Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

2020-05-06 Thread Jan Kara
On Wed 06-05-20 17:51:39, Souptick Joarder wrote: > On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote: > > > > On Wed 06-05-20 02:06:56, Souptick Joarder wrote: > > > On Wed, May 6, 2020 at 1:08 AM John Hubbard wrote: > > > > > > > > On 2020-05-05 12

Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()

2020-05-06 Thread Jan Kara
pily rely on the simple behavior of < 0 return on error or > 0 return if we mapped some pages. Callers that can possibly ask to map 0 pages can get 0 pages back - kind of expected - and I don't see any benefit in trying to rewrite these callers to handle -EINVAL instead... Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 17/18] udf: prevent bounds-check bypass via speculative execution

2018-01-08 Thread Jan Kara
memmove operations. In order to avoid potential leaks of kernel memory > values, block speculative execution of the instruction stream that could > issue further reads based on invalid 'aal' or 'ial' values. > > Based on an original patch by Elena Reshetova. > > C

Re: [PATCH 05/10] mm: replace get_vaddr_frames() write/force parameters with gup_flags

2016-10-19 Thread Jan Kara
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

Re: [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags

2016-10-19 Thread Jan Kara
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

Re: [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags

2016-10-19 Thread Jan Kara
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

Re: [PATCH 07/10] mm: replace get_user_pages_remote() write/force parameters with gup_flags

2016-10-19 Thread Jan Kara
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

Re: [PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

2016-10-19 Thread Jan Kara
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 |

Re: [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags

2016-10-19 Thread Jan Kara
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,

Re: [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags

2016-10-18 Thread Jan Kara
s second but I don't care that much. But it definitely should be consistent... Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 03/10] mm: replace get_user_pages_unlocked() write/force parameters with gup_flags

2016-10-18 Thread Jan Kara
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

Re: [PATCH 02/10] mm: remove write/force parameters from __get_user_pages_unlocked()

2016-10-18 Thread Jan Kara
> mm subsystem. > > Signed-off-by: Lorenzo Stoakes The patch looks good. You can add: Reviewed-by: Jan Kara Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH 01/10] mm: remove write/force parameters from __get_user_pages_locked()

2016-10-18 Thread Jan Kara
he mm subsystem. > > Signed-off-by: Lorenzo Stoakes Looks good. You can add: Reviewed-by: Jan Kara Honza -- Jan Kara SUSE Labs, CR

Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns

2016-06-02 Thread Jan Kara
em more... So cgroups would be probably the best fit for this but I'm not sure whether it is not an overkill... Honza -- Jan Kara SUSE Labs, CR

Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()

2016-04-26 Thread Jan Kara
On Tue 26-04-16 14:31:58, Nicolas Dichtel wrote: > Le 26/04/2016 13:08, Jan Kara a écrit : > > On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote: > >> Signed-off-by: Nicolas Dichtel > > > > OK, so I somewhat miss a description of what will this do to the netlink &

Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()

2016-04-26 Thread Jan Kara
A_NL_A_DEV_MINOR, > QUOTA_NL_A_CAUSED_ID, > + QUOTA_NL_A_PAD, > __QUOTA_NL_A_MAX, > }; > #define QUOTA_NL_A_MAX (__QUOTA_NL_A_MAX - 1) > -- > 2.8.1 > > -- Jan Kara SUSE Labs, CR

Re: yet another uninterruptable hang in sendfile

2015-11-23 Thread Jan Kara
: unrecognized netlink message: protocol=0 > nlmsg_type=0 sclass=netlink_route_socket > > The program should be killable. I don't have SELinux configured so that may be what's making a difference. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tree wide: Use kvfree() than conditional kfree()/vfree()

2015-11-09 Thread Jan Kara
addr(). Unless callers have special reasons, we can > replace this branch with kvfree(). Please check and reply if you found > problems. > > Signed-off-by: Tetsuo Handa > Acked-by: Michal Hocko You can add Acked-by: J

Re: [BUG] New Kernel Bugs

2007-11-13 Thread Jan Kara
lid (OK, I know the filesystem had to be corrupted somehow but unless this is at least occasionally reproducible, there's low chance of finding the bug). Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from

Re: [2/3] 2.6.23-rc6: known regressions v2

2007-09-18 Thread Jan Kara
> Submitter : Oliver Neukum <[EMAIL PROTECTED]> > Caused-By : ? > Handled-By : ? > Status : unknown I thought Shaggy asked Oliver about some details (and he did not answer so far) so I'd assume Shaggy is handling this.