linux-stable.git/drivers/net/ppp, branch v5.12.2

Merge tag 'tty-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2021-02-21T05:28:04+00:00

Pull tty/serial driver updates from Greg KH:
 "Here is the big set of tty/serial driver changes for 5.12-rc1.

  Nothing huge, just lots of good cleanups and additions:

   - n_tty line discipline cleanups

   - vt core cleanups and reworks to make the code more "modern"

   - stm32 driver additions

   - tty led support added to the tty core and led layer

   - minor serial driver fixups and additions

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'tty-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (54 commits)
  serial: core: Remove BUG_ON(in_interrupt()) check
  vt_ioctl: Remove in_interrupt() check
  dt-bindings: serial: imx: Switch to my personal address
  vt: keyboard, use new API for keyboard_tasklet
  serial: stm32: improve platform_get_irq condition handling in init_port
  serial: ifx6x60: Remove driver for deprecated platform
  tty: fix up iterate_tty_read() EOVERFLOW handling
  tty: fix up hung_up_tty_read() conversion
  tty: fix up hung_up_tty_write() conversion
  tty: teach the n_tty ICANON case about the new "cookie continuations" too
  tty: teach n_tty line discipline about the new "cookie continuations"
  tty: clean up legacy leftovers from n_tty line discipline
  tty: implement read_iter
  tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer
  serial: remove sirf prima/atlas driver
  serial: mxs-auart: Remove 
  serial: mxs-auart: Remove serial_mxs_probe_dt()
  serial: fsl_lpuart: Use of_device_get_match_data()
  dt-bindings: serial: renesas,hscif: Add r8a779a0 support
  tty: serial: Drop unused efm32 serial driver
  ...

ppp: use new tasklet API

2021-02-02T23:51:18+00:00

This converts the async and synctty drivers to use the new tasklet API n
commit 12cc923f1ccc ("tasklet: Introduce new initialization API")

Signed-off-by: Emil Renner Berthing 
Signed-off-by: Jakub Kicinski

Merge 5.11-rc5 into tty-next

2021-01-25T10:19:46+00:00

We need the fixes in here and this resolves a merge issue in
drivers/tty/tty_io.c

Signed-off-by: Greg Kroah-Hartman

Merge branch 'tty-splice' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into tty-next

2021-01-21T08:40:55+00:00

Fixes both the "splice/sendfile to a tty" and "splice/sendfile from a
tty" regression from 5.10.

* 'tty-splice' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux:
  tty: teach the n_tty ICANON case about the new "cookie continuations" too
  tty: teach n_tty line discipline about the new "cookie continuations"
  tty: clean up legacy leftovers from n_tty line discipline
  tty: implement read_iter
  tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer
  tty: implement write_iter

tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer

2021-01-21T00:48:47+00:00

The tty line discipline .read() function was passed the final user
pointer destination as an argument, which doesn't match the 'write()'
function, and makes it very inconvenient to do a splice method for
ttys.

This is a conversion to use a kernel buffer instead.

NOTE! It does this by passing the tty line discipline ->read() function
an additional "cookie" to fill in, and an offset into the cookie data.

The line discipline can fill in the cookie data with its own private
information, and then the reader will repeat the read until either the
cookie is cleared or it runs out of data.

The only real user of this is N_HDLC, which can use this to handle big
packets, even if the kernel buffer is smaller than the whole packet.

Cc: Christoph Hellwig 
Cc: Greg Kroah-Hartman 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2021-01-15T02:34:50+00:00

Signed-off-by: Jakub Kicinski

ppp: clean up endianness conversions

2021-01-09T03:26:23+00:00

sparse complains about some harmless endianness issues:

> drivers/net/ppp/pptp.c:281:21: warning: incorrect type in assignment (different base types)
> drivers/net/ppp/pptp.c:281:21:    expected unsigned int [usertype] ack
> drivers/net/ppp/pptp.c:281:21:    got restricted __be32
> drivers/net/ppp/pptp.c:283:23: warning: cast to restricted __be32

Here 'ack' is assigned a value in network-order, and then also the
byte-swapped value in host-order. Clean this up by doing the byte-swap
as part of the assignment.

> drivers/net/ppp/pptp.c:358:26: warning: cast from restricted __be16
> drivers/net/ppp/pptp.c:358:26: warning: incorrect type in argument 1 (different base types)
> drivers/net/ppp/pptp.c:358:26:    expected unsigned short [usertype] call_id
> drivers/net/ppp/pptp.c:358:26:    got restricted __be16 [usertype]

Here we use the wrong flavour of byte-swap. Use ntohs(), which of course
gives the same result.

Cc: Dmitry Kozlov 
Signed-off-by: Julian Wiedmann 
Link: https://lore.kernel.org/r/20210107143956.25549-1-jwi@linux.ibm.com
Signed-off-by: Jakub Kicinski

ppp: fix refcount underflow on channel unbridge

2021-01-09T03:21:06+00:00

When setting up a channel bridge, ppp_bridge_channels sets the
pch->bridge field before taking the associated reference on the bridge
file instance.

This opens up a refcount underflow bug if ppp_bridge_channels called
via. iotcl runs concurrently with ppp_unbridge_channels executing via.
file release.

The bug is triggered by ppp_bridge_channels taking the error path
through the 'err_unset' label.  In this scenario, pch->bridge is set,
but the reference on the bridged channel will not be taken because
the function errors out.  If ppp_unbridge_channels observes pch->bridge
before it is unset by the error path, it will erroneously drop the
reference on the bridged channel and cause a refcount underflow.

To avoid this, ensure that ppp_bridge_channels holds a reference on
each channel in advance of setting the bridge pointers.

Signed-off-by: Tom Parkin 
Fixes: 4cf476ced45d ("ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls")
Acked-by: Guillaume Nault 
Link: https://lore.kernel.org/r/20210107181315.3128-1-tparkin@katalix.com
Signed-off-by: Jakub Kicinski

ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls

2020-12-10T21:57:36+00:00

This new ioctl pair allows two ppp channels to be bridged together:
frames arriving in one channel are transmitted in the other channel
and vice versa.

The practical use for this is primarily to support the L2TP Access
Concentrator use-case.  The end-user session is presented as a ppp
channel (typically PPPoE, although it could be e.g. PPPoA, or even PPP
over a serial link) and is switched into a PPPoL2TP session for
transmission to the LNS.  At the LNS the PPP session is terminated in
the ISP's network.

When a PPP channel is bridged to another it takes a reference on the
other's struct ppp_file.  This reference is dropped when the channels
are unbridged, which can occur either explicitly on userspace calling
the PPPIOCUNBRIDGECHAN ioctl, or implicitly when either channel in the
bridge is unregistered.

In order to implement the channel bridge, struct channel is extended
with a new field, 'bridge', which points to the other struct channel
making up the bridge.

This pointer is RCU protected to avoid adding another lock to the data
path.

To guard against concurrent writes to the pointer, the existing struct
channel lock 'upl' coverage is extended rather than adding a new lock.

The 'upl' lock is used to protect the existing unit pointer.  Since the
bridge effectively replaces the unit (they're mutually exclusive for a
channel) it makes coding easier to use the same lock to cover them
both.

Signed-off-by: Tom Parkin 
Signed-off-by: David S. Miller

mm, treewide: rename kzfree() to kfree_sensitive()

2020-08-07T18:33:22+00:00

As said by Linus:

  A symmetric naming is only helpful if it implies symmetries in use.
  Otherwise it's actively misleading.

  In "kzalloc()", the z is meaningful and an important part of what the
  caller wants.

  In "kzfree()", the z is actively detrimental, because maybe in the
  future we really _might_ want to use that "memfill(0xdeadbeef)" or
  something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

  git grep -w --name-only kzfree |\
  xargs sed -i 's/kzfree/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.

[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
[akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

Suggested-by: Joe Perches 
Signed-off-by: Waiman Long 
Signed-off-by: Andrew Morton 
Acked-by: David Howells 
Acked-by: Michal Hocko 
Acked-by: Johannes Weiner 
Cc: Jarkko Sakkinen 
Cc: James Morris 
Cc: "Serge E. Hallyn" 
Cc: Joe Perches 
Cc: Matthew Wilcox 
Cc: David Rientjes 
Cc: Dan Carpenter 
Cc: "Jason A . Donenfeld" 
Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
Signed-off-by: Linus Torvalds