On Mon, 2021-04-05 at 11:52 +0200, Loic Poulain wrote:
> This change introduces initial support for a WWAN framework. Given
> the
> complexity and heterogeneity of existing WWAN hardwares and
> interfaces,
> there is no strict definition of what a WWAN device is and how it
> should
> be represented
On Fri, Mar 12, 2021 at 1:55 PM Chen, Mike Ximing
wrote:
>
>
>
> > -Original Message-----
> > From: Dan Williams
> > Sent: Friday, March 12, 2021 2:18 AM
> > To: Greg KH
> > Cc: Chen, Mike Ximing ; Netdev
> > ; David Miller
> > ; Jaku
On Wed, Mar 10, 2021 at 1:02 AM Greg KH wrote:
>
> On Wed, Feb 10, 2021 at 11:54:03AM -0600, Mike Ximing Chen wrote:
> > Intel DLB is an accelerator for the event-driven programming model of
> > DPDK's Event Device Library[2]. The library is used in packet processing
> > pipelines that arrange for
On Wed, Mar 10, 2021 at 12:14 AM Greg KH wrote:
>
> On Wed, Mar 10, 2021 at 02:45:10AM +, Chen, Mike Ximing wrote:
> >
> >
> > > -Original Message-
> > > From: Greg KH
> > > On Wed, Feb 10, 2021 at 11:54:17AM -0600, Mike Ximing Chen wrote:
> > > >
> > > > diff --git a/drivers/misc/dlb
On Mon, Mar 8, 2021 at 8:53 PM Chen, Mike Ximing
wrote:
>
>
> > -Original Message-
> > From: Greg KH
> > On Mon, Mar 08, 2021 at 08:00:00PM +, Chen, Mike Ximing wrote:
> > >
> > > Hi Greg,
> > >
> > > While waiting for the feedback from the networking maintainers, I am
> > > wondering
On Mon, Feb 1, 2021 at 4:40 PM Saleem, Shiraz wrote:
>
> > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and
> > implement private channel OPs
> >
> > On Sat, Jan 30, 2021 at 01:19:36AM +, Saleem, Shiraz wrote:
> > > > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an au
On Mon, 2021-02-01 at 19:27 +0100, Loic Poulain wrote:
> On Mon, 1 Feb 2021 at 19:17, Dan Williams wrote:
> > On Fri, 2021-01-29 at 18:21 -0800, Jakub Kicinski wrote:
> > > On Wed, 27 Jan 2021 18:01:17 +0100 Loic Poulain wrote:
> > > > MBIM has initially been specif
On Fri, 2021-01-29 at 18:21 -0800, Jakub Kicinski wrote:
> On Wed, 27 Jan 2021 18:01:17 +0100 Loic Poulain wrote:
> > MBIM has initially been specified by USB-IF for transporting data
> > (IP)
> > between a modem and a host over USB. However some modern modems
> > also
> > support MBIM over PCIe (v
On Mon, 2021-01-25 at 17:00 +0100, Bjørn Mork wrote:
> Dan Williams writes:
> > On Mon, 2021-01-25 at 00:33 -0700, Subash Abhinov Kasiviswanathan
> > wrote:
> > > Pass through mode is to allow packets in MAP format to be passed
> > > on to the stack. rmnet
On Mon, 2021-01-25 at 00:33 -0700, Subash Abhinov Kasiviswanathan
wrote:
> Pass through mode is to allow packets in MAP format to be passed
> on to the stack. rmnet driver can be used to process and demultiplex
> these packets.
>
> Pass through mode can be enabled when the device is in raw ip mode
On Wed, 2021-01-20 at 15:32 -0800, Jakub Kicinski wrote:
> On Wed, 20 Jan 2021 20:34:51 +0100 Andrew Lunn wrote:
> > On Sun, Jan 17, 2021 at 06:26:54PM +0100, Bjørn Mork wrote:
> > > I was young and stupid. Now I'm not that young anymore ;-)
> >
> > We all make mistakes, when we don't have the k
On Mon, Jan 4, 2021 at 5:53 PM Jason Gunthorpe wrote:
>
> On Mon, Jan 04, 2021 at 04:51:51PM -0800, Dan Williams wrote:
> > On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote:
> > >
> > > On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
> >
On Mon, Jan 4, 2021 at 4:14 PM Jason Gunthorpe wrote:
>
> On Mon, Jan 04, 2021 at 09:19:30PM +, Mark Brown wrote:
>
>
> > > Regardless of the shortcut to make everything a struct
> > > platform_device, I think it was a mistake to put OF devices on
> > > platform_bus. Those should have remained
On Fri, Dec 18, 2020 at 1:17 PM Alexandre Belloni
wrote:
>
> On 18/12/2020 16:58:56-0400, Jason Gunthorpe wrote:
> > On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
> >
> > > > So, I strongly suspect, MFD should create mfd devices on a MFD bus
> > > > type.
> > >
> > > Historically peo
On Thu, Dec 17, 2020 at 1:20 PM Alexandre Belloni
wrote:
>
> Hello,
>
> On 05/12/2020 16:51:36+0100, Greg KH wrote:
> > > To me, the documentation was written, and reviewed, more from the
> > > perspective of "why not open code a custom bus instead". So I can see
> > > after the fact how that is a
On Fri, 2020-12-11 at 08:44 +0100, Greg KH wrote:
> On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote:
> > This MHI client driver allows userspace clients to transfer
> > raw data between MHI device and host using standard file
> > operations.
> > Driver instantiates UCI device object wh
On Sat, Dec 5, 2020 at 4:24 PM David Ahern wrote:
>
> On 12/2/20 5:54 PM, Dan Williams wrote:
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index 8d7001712062..040be48ce046 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
&
On Fri, Dec 4, 2020 at 3:41 AM Greg KH wrote:
>
> On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > From: Dave Ertman
> >
> > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > It enables drivers to create a
On Thu, Dec 3, 2020 at 6:34 PM Jason Gunthorpe wrote:
>
> On Thu, Dec 03, 2020 at 04:06:24PM +0100, Greg KH wrote:
>
> > > ...for all the independent drivers to have a common commit baseline. It
> > > is not there yet pending Greg's Ack.
> >
> > I have been trying to carve out some time to review
: Leon Romanovsky
Signed-off-by: Dave Ertman
Reviewed-by: Pierre-Louis Bossart
Reviewed-by: Shiraz Saleem
Reviewed-by: Parav Pandit
Reviewed-by: Dan Williams
Reviewed-by: Martin Habets
Link:
https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com
Signed-off-by: Dan
> > Signed-off-by: Fred Oh
> > > Co-developed-by: Leon Romanovsky
> > > Signed-off-by: Leon Romanovsky
> > > Reviewed-by: Pierre-Louis Bossart
> > > Reviewed-by: Shiraz Saleem
> > > Reviewed-by: Parav Pandit
> > > Reviewed-by: Dan Wi
On Thu, 2020-11-12 at 17:08 +0100, Andrew Lunn wrote:
> On Wed, Nov 11, 2020 at 12:43:08PM -0800, Jian Yang wrote:
> > From: Mahesh Bandewar
> >
> > Traditionally loopback devices comes up with initial state as DOWN
> > for
> > any new network-namespace. This would mean that anyone needing this
>
On Thu, Nov 5, 2020 at 11:28 AM Ertman, David M
wrote:
[..]
> > > Each auxiliary_device represents a part of its parent
> > > +functionality. The generic behavior can be extended and specialized as
> > needed
> > > +by encapsulating an auxiliary_device within other domain-specific
> > structures a
On Thu, Nov 5, 2020 at 11:30 AM Leon Romanovsky wrote:
>
> On Thu, Nov 05, 2020 at 09:12:51AM -0800, Dan Williams wrote:
> > On Thu, Nov 5, 2020 at 1:47 AM Leon Romanovsky wrote:
> > >
> > > On Thu, Nov 05, 2020 at 01:19:09AM -0800, Dan Williams wrote:
> >
On Thu, Nov 5, 2020 at 11:40 AM Parav Pandit wrote:
>
>
>
> > From: Ertman, David M
> > Sent: Friday, November 6, 2020 12:58 AM
> > Subject: RE: [PATCH v3 01/10] Add auxiliary bus support
> >
> > > -Original Message-
> > > From: Dan Wi
On Thu, Nov 5, 2020 at 12:21 PM Greg KH wrote:
>
> On Thu, Nov 05, 2020 at 09:12:51AM -0800, Dan Williams wrote:
> > > >
> > > > Per above SPDX is v2 only, so...
> > >
> > > Isn't it default for the Linux kernel?
> >
> > SPD
On Thu, Nov 5, 2020 at 1:47 AM Leon Romanovsky wrote:
>
> On Thu, Nov 05, 2020 at 01:19:09AM -0800, Dan Williams wrote:
> > Some doc fixups, and minor code feedback. Otherwise looks good to me.
> >
> > On Thu, Oct 22, 2020 at 5:35 PM Dave Ertman
> > wrote:
> &g
; Co-developed-by: Ranjani Sridharan
> Signed-off-by: Ranjani Sridharan
> Co-developed-by: Fred Oh
> Signed-off-by: Fred Oh
> Co-developed-by: Leon Romanovsky
> Signed-off-by: Leon Romanovsky
> Reviewed-by: Pierre-Louis Bossart
> Reviewed-by: Shiraz Saleem
> Reviewed-by: Para
On Wed, Nov 4, 2020 at 11:32 PM gregkh wrote:
>
> On Wed, Nov 04, 2020 at 03:21:23PM -0800, Dan Williams wrote:
> > On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote:
> > [..]
> > > > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table);
> > > >
On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote:
[..]
> > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table);
> > +
> > +static struct auxiliary_driver mlx5v_driver = {
> > + .name = "vnet",
> > + .probe = mlx5v_probe,
> > + .remove = mlx5v_remove,
> > + .id_table = mlx5v_id_tabl
On Mon, 2020-10-26 at 07:38 -0600, Jeffrey Hugo wrote:
> On 10/25/2020 3:46 PM, Jakub Kicinski wrote:
> > On Fri, 23 Oct 2020 16:17:54 -0700 Hemant Kumar wrote:
> > > +UCI driver enables userspace clients to communicate to external
> > > MHI devices
> > > +like modem and WLAN. UCI driver probe crea
/drivers/nvdimm/claim.c
> +++ b/drivers/nvdimm/claim.c
> @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev,
> }
> break;
> default:
> len = -EBUSY;
> goto out_attach;
> - break;
> }
Acked-by: Dan Williams
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized t
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10 +---
On Fri, 2020-10-09 at 22:33 +0200, Loic Poulain wrote:
> This patch adds a new network driver implementing MHI transport for
> network packets. Packets can be in any format, though QMAP (rmnet)
> is the usual protocol (flow control + PDN mux).
>
> It support two MHI devices, IP_HW0 which is, the p
On Fri, Oct 9, 2020 at 7:27 AM Pierre-Louis Bossart
wrote:
>
>
>
> +
> + ancildrv->driver.owner = owner;
> + ancildrv->driver.bus = &ancillary_bus_type;
> + ancildrv->driver.probe = ancillary_probe_driver;
> + ancildrv->driver.remove = ancillary_remove_driver;
> >>
nds to
> > > an ancillary_device based on this id through the bus.
> > >
> > > Co-developed-by: Kiran Patil
> > > Signed-off-by: Kiran Patil
> > > Co-developed-by: Ranjani Sridharan
> > > Signed-off-by: Ranjani Sridharan
> > > Co-de
On Thu, Oct 8, 2020 at 1:00 AM Leon Romanovsky wrote:
>
> On Thu, Oct 08, 2020 at 12:38:00AM -0700, Dan Williams wrote:
> > On Thu, Oct 8, 2020 at 12:01 AM Leon Romanovsky wrote:
> > [..]
> > > All stated above is my opinion, it can be different from yours.
> >
On Thu, Oct 8, 2020 at 12:01 AM Leon Romanovsky wrote:
[..]
> All stated above is my opinion, it can be different from yours.
Yes, but we need to converge to move this forward. Jason was involved
in the current organization for registration, Greg was angling for
this to be core functionality. I h
On Wed, Oct 7, 2020 at 10:21 PM Leon Romanovsky wrote:
>
> On Wed, Oct 07, 2020 at 08:46:45PM +, Ertman, David M wrote:
> > > -Original Message-
> > > From: Parav Pandit
> > > Sent: Wednesday, October 7, 2020 1:17 PM
> > > To: Leon Romanovsky ; Ertman, David M
> > >
> > > Cc: Pierre-
On Wed, Oct 7, 2020 at 6:37 AM Leon Romanovsky wrote:
>
> On Wed, Oct 07, 2020 at 01:09:55PM +, Saleem, Shiraz wrote:
> > > Subject: Re: [PATCH v2 1/6] Add ancillary bus support
> > >
> > > On Tue, Oct 6, 2020 at 12:21 PM Leon Romanovsky wrote:
> > > >
> > > > On Tue, Oct 06, 2020 at 05:41:00
On Tue, Oct 6, 2020 at 12:21 PM Leon Romanovsky wrote:
>
> On Tue, Oct 06, 2020 at 05:41:00PM +, Saleem, Shiraz wrote:
> > > Subject: Re: [PATCH v2 1/6] Add ancillary bus support
> > >
> > > On Tue, Oct 06, 2020 at 05:09:09PM +, Parav Pandit wrote:
> > > >
> > > > > From: Leon Romanovsky
On Tue, 2020-10-06 at 08:40 -0400, Jes Sorensen wrote:
> On 10/6/20 3:45 AM, Arend Van Spriel wrote:
> > + Jes
> >
> > On 10/5/2020 4:12 PM, Kalle Valo wrote:
> > > Greg Kroah-Hartman writes:
> > >
> > > > On Fri, Oct 02, 2020 at 01:53:58PM +0200, Sebastian Andrzej
> > > > Siewior
> > > > wrote:
On Thu, Jul 2, 2020 at 6:44 AM Ranjani Sridharan
wrote:
[..]
> > > Hi Jason,
> > >
> > > We're addressing the naming in the next version as well. We've had
> > > several people reject the name virtual bus and we've narrowed in on
> > > "ancillary bus" for the new name suggesting that we have the c
On Thu, 2020-06-18 at 12:08 +0200, Tanjeff-Nicolai Moos wrote:
>
> On Wed, 17 Jun 2020 19:24:34 +0200
> Andrew Lunn wrote:
>
> > On Wed, Jun 17, 2020 at 11:59:33AM -0500, Dan Williams wrote:
> > > On Wed, 2020-06-17 at 18:48 +0200, Andrew Lunn wrote:
> > >
On Wed, 2020-06-17 at 19:24 +0200, Andrew Lunn wrote:
> On Wed, Jun 17, 2020 at 11:59:33AM -0500, Dan Williams wrote:
> > On Wed, 2020-06-17 at 18:48 +0200, Andrew Lunn wrote:
> > > On Wed, Jun 17, 2020 at 03:21:53PM +0200, Tanjeff-Nicolai Moos
> > >
On Wed, 2020-06-17 at 18:48 +0200, Andrew Lunn wrote:
> On Wed, Jun 17, 2020 at 03:21:53PM +0200, Tanjeff-Nicolai Moos wrote:
> > Hi netdevs,
> >
> > Kernel version:
> >
> > I'm working with kernel 4.14.137 (OpenWRT project). But I looked
> > at
> > the source of kernel 5.7 and found the same
On Tue, Jun 9, 2020 at 12:57 PM David Miller wrote:
>
> From: "Williams, Dan J"
> Date: Tue, 9 Jun 2020 19:30:50 +
>
> > On Tue, 2020-06-09 at 11:36 -0700, David Miller wrote:
> >> From: Stephen Hemminger
> >> Date: Tue, 9 Jun 2020 10:19:35 -0700
> >>
> >> > Yes, words do matter and convey a
On Thu, 2019-06-27 at 12:20 -0700, Stephen Hemminger wrote:
> On Thu, 27 Jun 2019 20:39:48 +0200
> Michal Kubecek wrote:
>
> > > $ ip li set dev enp3s0 alias "Onboard Ethernet"
> > > # ip link show "Onboard Ethernet"
> > > Device "Onboard Ethernet" does not exist.
> > >
> > > So it does not real
On Thu, 2019-06-27 at 08:29 -0700, Stephen Hemminger wrote:
> On Thu, 27 Jun 2019 11:43:27 +0200
> Jiri Pirko wrote:
>
> > Hi all.
> >
> > In the past, there was repeatedly discussed the IFNAMSIZ (16) limit
> > for
> > netdevice name length. Now when we have PF and VF representors
> > with port
On Thu, 2019-04-04 at 11:00 +0200, Johannes Berg wrote:
> Hi,
>
> > Thanks a lot for doing this! Being responsible for most of the
> > issues
> > you point out, I can only say that you have my full support if you
> > want
> > to change any of it.
>
> :-)
>
> > My pathetic excuses below are just
On Sat, 2019-03-02 at 22:19 +0100, Kristian Evensen wrote:
> On Sat, Mar 2, 2019 at 4:00 PM Bjørn Mork wrote:
> > I am not too happy about the double device id matching with extra
> > magic
> > applied. outside the device id table. It does not scale, and it
> > does
> > not play well at all with
On Thu, 2019-02-28 at 10:38 -0800, Stephen Hemminger wrote:
> From: Stephen Hemminger
>
> Give a reason for returning error for bpf setup.
>
> Signed-off-by: Stephen Hemminger
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 25 +--
>
> 1 file changed, 18 insertions(+),
On Mon, Feb 11, 2019 at 2:07 PM Jason Gunthorpe wrote:
>
> On Mon, Feb 11, 2019 at 01:52:38PM -0800, Ira Weiny wrote:
> > On Mon, Feb 11, 2019 at 01:39:12PM -0800, John Hubbard wrote:
> > > On 2/11/19 1:26 PM, Ira Weiny wrote:
> > > > On Mon, Feb 11, 2019 at 01:13:56PM -0800, John Hubbard wrote:
>
On Mon, Feb 11, 2019 at 1:39 PM John Hubbard wrote:
>
> On 2/11/19 1:26 PM, Ira Weiny wrote:
> > On Mon, Feb 11, 2019 at 01:13:56PM -0800, John Hubbard wrote:
> >> On 2/11/19 12:39 PM, Jason Gunthorpe wrote:
> >>> On Mon, Feb 11, 2019 at 12:16:42PM -0800, ira.we...@intel.com wrote:
> From: Ir
[ add Ira ]
On Mon, Feb 11, 2019 at 7:33 AM Daniel Borkmann wrote:
>
> [ +Dan ]
>
> On 02/07/2019 08:43 AM, Björn Töpel wrote:
> > Den tors 7 feb. 2019 kl 06:38 skrev Davidlohr Bueso :
> >>
> >> Holding mmap_sem exclusively for a gup() is an overkill.
> >> Lets replace the call for gup_fast() and
On Mon, Jan 7, 2019 at 2:25 PM Michael S. Tsirkin wrote:
>
> On Mon, Jan 07, 2019 at 01:39:15PM -0800, Dan Williams wrote:
> > On Mon, Jan 7, 2019 at 6:11 AM Michael S. Tsirkin wrote:
> > >
> > > On Sun, Jan 06, 2019 at 11:15:20PM -0800, Dan Williams wrote:
> >
On Mon, Jan 7, 2019 at 6:11 AM Michael S. Tsirkin wrote:
>
> On Sun, Jan 06, 2019 at 11:15:20PM -0800, Dan Williams wrote:
> > On Sun, Jan 6, 2019 at 8:17 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote:
>
; You mean __uaccess_begin_nospec introduced by
> commit 304ec1b050310548db33063e567123fae8fd0301
> ?
>
> So fundamentally we do access_ok checks when supplying
> the memory table to the kernel thread, and we should
> do the spec barrier there.
>
> Then we can just cre
sure
> there can't be any other type of serial function with 3 endpoints and
> ff/ff/ff? Well, I guess no one knows for sure... And this is more
> than
> good enough until it breaks. Thanks for solving the puzzle. Looks
> good
> to me.
I'm sure they could add another ser
On Tue, 2018-06-05 at 11:38 +0200, Daniele Palmas wrote:
> Hi,
>
> 2018-02-21 20:47 GMT+01:00 Subash Abhinov Kasiviswanathan
> :
> > On 2018-02-21 04:38, Daniele Palmas wrote:
> > >
> > > Hello,
> > >
> > > in rmnet kernel documentation I read:
> > >
> > > "This driver can be used to register o
On Sun, 2018-04-15 at 18:16 +0200, Pavel Machek wrote:
> On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> > On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > >
On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > >
> > > Broken state.
> > >
> > > pavel@amd:~$ nmcli dev
> > > DEVICE TYPE STATECONNECTION
> > > eth1ethernet unavailable --
> > > lo loopback unmanaged
On Tue, 2018-03-20 at 09:03 +0100, Pavel Machek wrote:
> On Mon 2018-03-19 12:45:49, Dan Williams wrote:
> > On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > > > On Mon, 2018-03-19 at 10:21 +0100, Pavel
On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:
> On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > Pavel Machek wrote:
> > > &
On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > Pavel Machek wrote:
> > > Hi!
> > >
> > > With recent linux-next, after resume networkmanager often claims
> > > that
> > > "network is disabled". Sometimes suspend/resume clears that.
>
to prevent userspace-controlled arbitrary out-of-bounds speculation, a
precursor for a speculative execution side channel vulnerability.
Cc:
Cc: "David S. Miller"
Cc: Eric W. Biederman
Signed-off-by: Dan Williams
---
net/mpls/af_mpls.c | 24 ++--
1 file changed,
On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon wrote:
> Hi Dan, Linus,
>
> On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote:
>> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
>> wrote:
>> > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams
>&
On Fri, Jan 12, 2018 at 12:01 PM, Christian Lamparter
wrote:
> On Friday, January 12, 2018 7:39:50 PM CET Dan Williams wrote:
>> On Fri, Jan 12, 2018 at 6:42 AM, Christian Lamparter
>> wrote:
>> > On Friday, January 12, 2018 1:47:46 AM CET Dan Williams wrote:
>> &
On Thu, Jan 11, 2018 at 11:59 PM, Greg KH wrote:
> On Thu, Jan 11, 2018 at 04:47:18PM -0800, Dan Williams wrote:
>> Static analysis reports that 'offset' may be a user controlled value
>> that is used as a data dependency reading from a raw_frag_vec buffer.
>> In or
On Fri, Jan 12, 2018 at 6:42 AM, Christian Lamparter wrote:
> On Friday, January 12, 2018 1:47:46 AM CET Dan Williams wrote:
>> Static analysis reports that 'queue' may be a user controlled value that
>> is used as a data dependency to read from the 'ar9170_qma
On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
wrote:
> On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams
> wrote:
>>
>> This series incorporates Mark Rutland's latest ARM changes and adds
>> the x86 specific implementation of 'ifence_array_ptr'. That ifence
ased on an invalid '*(rfv->c + offset)' value.
Based on an original patch by Elena Reshetova.
Cc: "David S. Miller"
Cc: Alexey Kuznetsov
Cc: Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org
Signed-off-by: Elena Reshetova
Signed-off-by: Dan Williams
---
net/ipv4/raw.c |
vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Elena Reshetova
Signed-off-by: Dan Williams
---
drivers/net/wireless/ath/carl9170/main.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/main.c
b/drivers/net/wireless/ath/ca
issue reads
based on an invalid result of 'priv->qos_params[queue]'.
Based on an original patch by Elena Reshetova.
Cc: Christian Lamparter
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Elena Reshetova
Signed-off-by: Dan Williams
---
driv
ger.kernel.org
Signed-off-by: Elena Reshetova
Signed-off-by: Dan Williams
---
drivers/net/wireless/st/cw1200/sta.c | 11 +++
drivers/net/wireless/st/cw1200/wsm.h |4 +---
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/st/cw1200/sta.c
b/dr
er in the
kernel a pointer too far, especially given the current array_ptr()
implementation.
Cc: "David S. Miller"
Cc: Eric W. Biederman
Cc: netdev@vger.kernel.org
Signed-off-by: Elena Reshetova
Signed-off-by: Dan Williams
---
net/mpls/af_mpls.c | 12 +++-
1 file changed
ased on an invalid '*(rfv->c + offset)' value.
Based on an original patch by Elena Reshetova.
Cc: "David S. Miller"
Cc: Alexey Kuznetsov
Cc: Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org
Signed-off-by: Elena Reshetova
Signed-off-by: Dan Williams
---
net/ipv6/raw.c |
git branch
here:
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v2
Note that the BPF fix for Spectre variant1 is merged in the bpf.git
tree [4], and is not included in this branch.
[2]:
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memor
On Sat, Jan 6, 2018 at 1:03 AM, Greg KH wrote:
> On Fri, Jan 05, 2018 at 05:10:48PM -0800, Dan Williams wrote:
>> Static analysis reports that 'handle' may be a user controlled value
>> that is used as a data dependency to read 'sp' from the
>> 're
On Thu, Jan 11, 2018 at 1:54 AM, Jiri Kosina wrote:
> On Tue, 9 Jan 2018, Josh Poimboeuf wrote:
>
>> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
>> > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina wrote:
>> > > On Fri, 5 Jan 2018, Dan William
On Tue, Jan 9, 2018 at 5:57 PM, Alexei Starovoitov
wrote:
> On Tue, Jan 09, 2018 at 04:48:24PM -0800, Dan Williams wrote:
>>
>> #define __nospec_array_ptr(base, idx, sz) \
>> ({
On Tue, Jan 9, 2018 at 4:48 PM, Dan Williams wrote:
> On Mon, Jan 8, 2018 at 8:13 PM, Linus Torvalds
> wrote:
>>
>> On Mon, Jan 8, 2018 at 7:42 PM, Dan Williams
>> wrote:
>> >
>> > originally from Linus and tweaked by Alexei and I:
>>
On Tue, Jan 9, 2018 at 4:54 PM, Eric W. Biederman wrote:
> Dan Williams writes:
[..]
> Sigh.
> I am not worrying about what is in the speculation window. My
> assumption is that the speculation window could be infinite, as we don't
> know the limitations of all possible
On Mon, Jan 8, 2018 at 8:13 PM, Linus Torvalds
wrote:
>
> On Mon, Jan 8, 2018 at 7:42 PM, Dan Williams wrote:
> >
> > originally from Linus and tweaked by Alexei and I:
>
> Sadly, that tweak - while clever - is wrong.
>
> > unsigned long _mask = ~(long)(
On Tue, Jan 9, 2018 at 2:23 PM, Josh Poimboeuf wrote:
> On Tue, Jan 09, 2018 at 01:59:04PM -0800, Dan Williams wrote:
>> > Right, but what's the purpose of preventing speculation past
>> > access_ok()?
>>
>> Caution. It's the same rationale for the n
On Tue, Jan 9, 2018 at 1:49 PM, Josh Poimboeuf wrote:
> On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote:
>> On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote:
>> > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
>> >> On Fri, Jan 5,
On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote:
> On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
>> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
>> wrote:
>> > From: Andi Kleen
>> >
>> > When access_ok fails we should alwa
On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Dan Williams wrote:
>
> [ ... snip ... ]
>> Andi Kleen (1):
>> x86, barrier: stop speculation for failed access_ok
>>
>> Dan Williams (13):
>> x86: implement nospec_barri
On Tue, Jan 9, 2018 at 8:17 AM, Eric W. Biederman wrote:
> Dan Williams writes:
[..]
> The user controlled value condition of your patchset implies that you
> assume indirect branch predictor poisoning is handled in other ways.
>
> Which means that we can assume speculation
On Mon, Jan 8, 2018 at 7:11 PM, Eric W. Biederman wrote:
> Dan Williams writes:
>
>> Static analysis reports that 'index' may be a user controlled value that
>> is used as a data dependency reading 'rt' from the 'platform_label'
>> arra
On Mon, Jan 8, 2018 at 3:23 AM, Laurent Pinchart
wrote:
> Hi Dan,
>
> Thank you for the patch.
>
> On Saturday, 6 January 2018 03:10:32 EET Dan Williams wrote:
>> Static analysis reports that 'index' may be a user controlled value that
>> is used as a d
On Mon, Jan 8, 2018 at 3:44 PM, Linus Torvalds
wrote:
> On Mon, Jan 8, 2018 at 1:09 PM, Dan Williams wrote:
>> On Sat, Jan 6, 2018 at 5:20 PM, Linus Torvalds
>> wrote:
>>> On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams
>>> wrote:
>>>>
>>>>
On Sat, Jan 6, 2018 at 5:20 PM, Linus Torvalds
wrote:
> On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams wrote:
>>
>> I assume if we put this in uaccess_begin() we also need audit for
>> paths that use access_ok but don't do on to call uaccess_begin()? A
>> quick gl
On Sun, Jan 7, 2018 at 11:47 AM, Linus Torvalds
wrote:
> On Sat, Jan 6, 2018 at 10:33 PM, Willy Tarreau wrote:
>>
>> To be fair there's overreaction on both sides. The vast majority of
>> users need to get a 100% safe system and will never notice any
>> difference.
>
> There is no such thing as
On Sun, Jan 7, 2018 at 1:09 AM, Greg KH wrote:
[..]
> Sorry for the confusion, no, I don't mean the "taint tracking", I mean
> the generic pattern of "speculative out of bounds access" that we are
> fixing here.
>
> Yes, as you mentioned before, there are tons of false-positives in the
> tree, as
On Fri, Jan 5, 2018 at 7:09 PM, Linus Torvalds
wrote:
> On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
> wrote:
>>
>> The fact is, we have to stop speculating when access_ok() does *not*
>> fail - because that's when we'll actually do the access. And it's that
>> access that needs to be non-specu
On Sat, Jan 6, 2018 at 11:37 AM, Dan Williams wrote:
> On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One
On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed und
On Sat, Jan 6, 2018 at 11:25 AM, Alexei Starovoitov
wrote:
> On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote:
>> On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
>> wrote:
>> [..]
>> >> retpoline is variant-2, this patch series is about varian
1 - 100 of 414 matches
Mail list logo
