Re: [PATCH net-next 5/5] ppp: handle PPPIOCGIDLE for 64-bit time_t

On Wed, Aug 29, 2018 at 04:03:30PM +0200, Arnd Bergmann wrote: > The ppp_idle structure is defined in terms of __kernel_time_t, which is > defined as 'long' on all architectures, and this usage is not affected > by the y2038 problem since it transports a time interval rather than an > absolute

Re: [PATCH net-next 3/5] ppp: move PPPIOCSCOMPRESS32 to ppp-generic.c

ler to do > it in the regular ioctl handler, by allowing both structure layouts to > be handled directly there. > Acked-by: Guillaume Nault

Re: [PATCH net-next 4/5] ppp: move PPPIOCSPASS32/PPPIOCSACTIVE32 to ppp_generic.c

ntation I could come up with was to merge > the compat handling into the regular ppp_ioctl() function and > treating all ioctl commands as compatible. > Acked-by: Guillaume Nault

Re: [PATCH net-next 1/5] pppoe: fix PPPOEIOCSFWD compat handling

should probably have removed this ioctl entirely instead of fixing it. Clearly, it has never been used. If you think it's worth fixing (as opposed to dropping this ioctl or its compat mode), then, Acked-by: Guillaume Nault

Re: [PATCH v2] ppp: remove the PPPIOCDETACH ioctl

table submissions himself. Using a 'PATCH net' subject prefix would have made it clear that this patch was fixing some released code and should be considered for -stable backport. Reviewed-by: Guillaume Nault <g.na...@alphalink.fr> Tested-by: Guillaume Nault <g.na...@alphalink.fr>

Re: [PATCH] ppp: remove the PPPIOCDETACH ioctl

On Tue, May 22, 2018 at 08:59:52PM -0700, Eric Biggers wrote: > From: Eric Biggers > > The PPPIOCDETACH ioctl effectively tries to "close" the given ppp file > before f_count has reached 0, which is fundamentally a bad idea. It > does check 'f_count < 2', which excludes

Re: KASAN: use-after-free Read in remove_wait_queue (2)

On Tue, May 22, 2018 at 08:29:58PM -0700, Eric Biggers wrote: > On Fri, May 18, 2018 at 06:02:23PM +0200, Guillaume Nault wrote: > > On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote: > > > [+ppp list and maintainer] > > > > > > This is a bug in ppp_

Re: KASAN: use-after-free Read in remove_wait_queue (2)

On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote: > [+ppp list and maintainer] > > This is a bug in ppp_generic.c; it still happens on Linus' tree and it's > easily > reproducible, see program below. The bug is that the PPPIOCDETACH ioctl > doesn't > consider that the file can

Re: [PATCH] slip: Check if rstate is initialized before uncompressing

On Wed, Apr 04, 2018 at 04:21:25PM +0530, Tejaswi Tanikella wrote: > On receiving a packet the state index points to the rstate which must be > used to fill up IP and TCP headers. But if the state index points to a > rstate which is unitialized, i.e. filled with zeros, it gets stuck in an >

Re: possible deadlock in ppp_dev_uninit

On Wed, Jan 03, 2018 at 10:58:01PM -0800, syzbot wrote: > Hello, > > > WARNING: possible recursive locking detected > 4.15.0-rc6-next-20180103+ #87 Not tainted > > syzkaller221540/3462 is trying to acquire

Re: [PATCH net-next] ppp: Destroy the mutex when cleanup

/drivers/net/ppp/ppp_generic.c > +++ b/drivers/net/ppp/ppp_generic.c > @@ -960,6 +960,7 @@ static __net_exit void ppp_exit_net(struct net *net) > unregister_netdevice_many(); > rtnl_unlock(); > > + mutex_destroy(>all_ppp_mutex); > idr_destroy(&

Re: BUG in free_netdev() on ppp link deletion

On Tue, Oct 03, 2017 at 06:40:03PM +0200, Guillaume Nault wrote: > On Tue, Oct 03, 2017 at 09:44:14AM +0200, Beniamino Galvani wrote: > > Call Trace: > > ppp_destroy_interface+0xd8/0xe0 [ppp_generic] > > ppp_disconnect_channel+0xda/0x110 [ppp_generic] > > ppp_un

Re: BUG in free_netdev() on ppp link deletion

On Tue, Oct 03, 2017 at 09:44:14AM +0200, Beniamino Galvani wrote: > Call Trace: > ppp_destroy_interface+0xd8/0xe0 [ppp_generic] > ppp_disconnect_channel+0xda/0x110 [ppp_generic] > ppp_unregister_channel+0x5e/0x110 [ppp_generic] > pppox_unbind_sock+0x23/0x30 [pppox] >

Re: [PATCH] driver: ppp: Remove unnecessary bh disable in xmit path

On Thu, Jun 01, 2017 at 09:49:18AM +0800, gfree.w...@vip.163.com wrote: > From: Gao Feng > > Since the commit 55454a565836 ("ppp: avoid dealock on recursive xmit"), > the PPP xmit path is protected by wrapper functions which disable the > bh already. So it is unnecessary

[PATCH v4 net-next 2/2] ppp: add rtnetlink device creation support

based PPP interfaces: in the device name, the number following the "ppp" prefix corresponds to the PPP unit number for ioctl based devices, while it is just an unrelated incrementing index for rtnl ones. Signed-off-by: Guillaume Nault <g.na...@alphalink.fr> --- drivers/n

[PATCH v4 net-next 1/2] ppp: define reusable device creation functions

eed to return a ppp structure to ppp_unattached_ioctl() anymore. * The unit parameter is made read/write so that ppp_create_interface() can tell which unit number has been assigned. Signed-off-by: Guillaume Nault <g.na...@alphalink.fr> --- drivers/net/ppp/ppp_generi

[PATCH v4 net-next 0/2] ppp: add rtnetlink support

hen Hemminger). - Do file descriptor lookup directly in ppp_nl_newlink(), to simplify ppp_dev_configure(). Changes since v1: - Rebase on net-next. - Invert locking order wrt. ppp_mutex and rtnl_lock and protect file->private_data with ppp_mutex. Guillaume Nault (2): ppp: define

[RFC PATCH v3 1/2] ppp: define reusable device creation functions

eed to return a ppp structure to ppp_unattached_ioctl() anymore. * The unit parameter is made read/write so that ppp_create_interface() can tell which unit number has been assigned. Signed-off-by: Guillaume Nault <g.na...@alphalink.fr> --- drivers/net/ppp/ppp_generi

[RFC PATCH v3 2/2] ppp: add rtnetlink device creation support

based PPP interfaces: in the device name, the number following the "ppp" prefix corresponds to the PPP unit number for ioctl based devices, while it is just an unrelated incrementing index for rtnl ones. Signed-off-by: Guillaume Nault <g.na...@alphalink.fr> --- drivers/n

[RFC PATCH v3 0/2] ppp: add rtnetlink support

file descriptor lookup directly in ppp_nl_newlink(), to simplify ppp_dev_configure(). Changes since v1: - Rebase on net-next. - Invert locking order wrt. ppp_mutex and rtnl_lock and protect file->private_data with ppp_mutex. Guillaume Nault (2): ppp: define reusable device cre