Re: [PATCH] staging: isdn: To make hysdn_proc_entry static.
On Sun, Jun 09, 2019 at 12:24:59AM +, Rishiraj Manwatkar wrote: > Made hysdn_proc_entry static as suggested by Sparse tool. Why is this indented? > > Signed-off-by: Rishiraj Manwatkar > --- > drivers/staging/isdn/hysdn/hysdn_procconf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/isdn/hysdn/hysdn_procconf.c > b/drivers/staging/isdn/hysdn/hysdn_procconf.c > index 73079213ec94..3d12c058a6f1 100644 > --- a/drivers/staging/isdn/hysdn/hysdn_procconf.c > +++ b/drivers/staging/isdn/hysdn/hysdn_procconf.c > @@ -349,7 +349,7 @@ static const struct file_operations conf_fops = > /*/ > /* hysdn subdir in /proc/net */ > /*/ > -struct proc_dir_entry *hysdn_proc_entry = NULL; > +static struct proc_dir_entry *hysdn_proc_entry = NULL; I will have to wait until after 5.3-rc1 before taking any drivers/staging/isdn patches, sorry. I suggest waiting until then before resending, and even then, the isdn code is about to be deleted, try working on code that is being accepted. thanks, greg k-h
Re: [PATCH 03/17] mlx5: no need to check return value of debugfs_create functions
On Tue, Aug 06, 2019 at 07:41:57PM +, Saeed Mahameed wrote:
> On Tue, 2019-08-06 at 18:11 +0200, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic
> > should
> > never do something different based on this.
> >
> > This cleans up a lot of unneeded code and logic around the debugfs
> > files, making all of this much simpler and easier to understand as we
> > don't need to keep the dentries saved anymore.
> >
>
> Hi Greg,
>
> Basically i am ok with this patch and i like it very much.., but i am
> concerned about some of the driver internal flows that are dependent on
> these debug fs entries being valid.
That's never good, that's a bug in the driver :)
> for example mlx5_debug_eq_add if failed, it will fail the whole flow. I
> know it is wrong even before your patch.. but maybe we should deal with
> it now ? or let me know if you want me to follow up with my own patch.
Your own patch would be good as I do not know this part of the codebase
at all, thanks.
> All we need to improve in this patch is to void out add_res_tree()
> implemented in
> drivers/net/ethernet/mellanox/mlx5/core/debugfs.c
> as i will comment below.
>
>
> > Cc: Saeed Mahameed
> > Cc: Leon Romanovsky
> > Cc: netdev@vger.kernel.org
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 51 ++---
> > .../net/ethernet/mellanox/mlx5/core/debugfs.c | 102 ++
> >
> > drivers/net/ethernet/mellanox/mlx5/core/eq.c | 11 +-
> > .../net/ethernet/mellanox/mlx5/core/lib/eq.h | 2 +-
> > .../net/ethernet/mellanox/mlx5/core/main.c| 7 +-
> > .../ethernet/mellanox/mlx5/core/mlx5_core.h | 2 +-
> > include/linux/mlx5/driver.h | 12 +--
> > 7 files changed, 24 insertions(+), 163 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> > index 8cdd7e66f8df..973f90888b1f 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> > @@ -1368,49 +1368,19 @@ static void clean_debug_files(struct
> > mlx5_core_dev *dev)
> > debugfs_remove_recursive(dbg->dbg_root);
> > }
> >
>
> [...]
>
> > void mlx5_cq_debugfs_cleanup(struct mlx5_core_dev *dev)
> > {
> > - if (!mlx5_debugfs_root)
> > - return;
> > -
> > debugfs_remove_recursive(dev->priv.cq_debugfs);
> > }
> >
> > @@ -484,7 +418,6 @@ static int add_res_tree(struct mlx5_core_dev
>
> Basically this function is a debugfs wrapper that should behave the
> same as debug_fs_*, we should fix it to return void as well, and
> improve all the its callers to ignore the return value.
But mlx5_cq_debugfs_cleanup() is a void function.
> callers are:
> mlx5_debug_qp_add()
> mlx5_debug_eq_add()
> mlx5_debug_cq_add()
Ah, you mean add_res_tree(). Yes, make that void as well.
thanks,
greg k-h
Re: [PATCH v10 01/20] dlb: add skeleton for DLB driver
On Thu, Feb 18, 2021 at 07:34:31AM +, Chen, Mike Ximing wrote: > > > > -Original Message- > > From: Mike Ximing Chen > > Sent: Wednesday, February 10, 2021 12:54 PM > > To: netdev@vger.kernel.org > > Cc: da...@davemloft.net; k...@kernel.org; a...@arndb.de; > > gre...@linuxfoundation.org; Williams, Dan J ; > > pierre- > > louis.boss...@linux.intel.com; Gage Eads > > Subject: [PATCH v10 01/20] dlb: add skeleton for DLB driver > > > > diff --git a/Documentation/misc-devices/dlb.rst b/Documentation/misc- > > devices/dlb.rst > > new file mode 100644 > > index ..aa79be07ee49 > > --- /dev/null > > +++ b/Documentation/misc-devices/dlb.rst > > @@ -0,0 +1,259 @@ > > +.. SPDX-License-Identifier: GPL-2.0-only > > + > > +=== > > +Intel(R) Dynamic Load Balancer Overview > > +=== > > + > > +:Authors: Gage Eads and Mike Ximing Chen > > + > > +Contents > > + > > + > > +- Introduction > > +- Scheduling > > +- Queue Entry > > +- Port > > +- Queue > > +- Credits > > +- Scheduling Domain > > +- Interrupts > > +- Power Management > > +- User Interface > > +- Reset > > + > > +Introduction > > + > > + > > +The Intel(r) Dynamic Load Balancer (Intel(r) DLB) is a PCIe device that > > +provides load-balanced, prioritized scheduling of core-to-core > > communication. > > + > > +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 multi-core scalability, dynamic load-balancing, > > and > > +variety of packet distribution and synchronization schemes. > > + > > +Intel DLB device consists of queues and arbiters that connect producer > > +cores and consumer cores. The device implements load-balanced queueing > > features > > +including: > > +- Lock-free multi-producer/multi-consumer operation. > > +- Multiple priority levels for varying traffic types. > > +- 'Direct' traffic (i.e. multi-producer/single-consumer) > > +- Simple unordered load-balanced distribution. > > +- Atomic lock free load balancing across multiple consumers. > > +- Queue element reordering feature allowing ordered load-balanced > > distribution. > > + > > Hi Jakub/Dave, > This is a device driver for a HW core-to-core communication accelerator. It > is submitted > to "linux-kernel" for a module under device/misc. Greg suggested (see below) > that we > also sent it to you for any potential feedback in case there is any > interaction with > networking initiatives. The device is used to handle the load balancing among > CPU cores > after the packets are received and forwarded to CPU. We don't think it > interferes > with networking operations, but would appreciate very much your > review/comment on this. It's the middle of the merge window, getting maintainers to review new stuff until after 5.12-rc1 is out is going to be a very difficult thing to do. In the meantime, why don't you all help out and review submitted patches to the mailing lists for the subsystems you all are trying to get this patch into. I know maintainers would appreciate the help, right? thanks, greg k-h
Re: [PATCH] e1000e: use proper #include guard name in hw.h
On Tue, Mar 02, 2021 at 01:37:59AM +, Nguyen, Anthony L wrote: > On Sat, 2021-02-27 at 10:58 +0100, Greg Kroah-Hartman wrote: > > The include guard for the e1000e and e1000 hw.h files are the same, > > so > > add the proper "E" term to the hw.h file for the e1000e driver. > > There's a patch in process that addresses this issue [1]. Thanks, hopefully it gets fixed somehow :) greg k-h
Re: [patch net] devlink: convert occ_get op to separate registration
On Tue, Apr 10, 2018 at 08:43:31PM +, Sasha Levin wrote: > >Bots are starting to overwhelm actual content from human beings > >on this list, and I want to put my foot on the brake right now > >before it gets even more out of control. > > I think we're just hitting the limitations of using a mailing list. Bots > aren't around to spam everyone for fun, right? > > 0day bot is spammy because patches fail to compile, syzbot is spammy > because we have tons of bugs users can hit and the stable bot is > spammy because we miss lots of commits that should be in stable. > > As the kernel grows, not only the codebase is expanding but also the > tooling around it. While spammy, bots provide valuable input that in the > past would take blood, sweat and tears to acquire. We just need a better > way to consume it rather than blocking off these inputs. As one of the primary abusers of the "I send too much email" flood of mess, I'm going to start cutting down on what type of message I respond to a public vger list from now on. I'll write more on the stable@ list about this, but for your individual patches like this, how about just responding to the developers themselves and not a public list? I do that when I commit a patch to my tree, stripping out lists, as it's not a useful message for anyone other than the person who wrote the patch and the reviewers. thanks, greg k-h
Re: Bluetooth: Prevent stack info leak from the EFS element.
On Tue, Jan 02, 2018 at 12:26:15PM -0800, Guenter Roeck wrote: > On Fri, Dec 08, 2017 at 03:14:47PM +0100, gre...@linuxfoundation.org wrote: > > From: Ben Seri > > > > In the function l2cap_parse_conf_rsp and in the function > > l2cap_parse_conf_req the following variable is declared without > > initialization: > > > > struct l2cap_conf_efs efs; > > > > In addition, when parsing input configuration parameters in both of > > these functions, the switch case for handling EFS elements may skip the > > memcpy call that will write to the efs variable: > > > > ... > > case L2CAP_CONF_EFS: > > if (olen == sizeof(efs)) > > memcpy(&efs, (void *)val, olen); > > ... > > > > The olen in the above if is attacker controlled, and regardless of that > > if, in both of these functions the efs variable would eventually be > > added to the outgoing configuration request that is being built: > > > > l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs), (unsigned long) &efs); > > > > So by sending a configuration request, or response, that contains an > > L2CAP_CONF_EFS element, but with an element length that is not > > sizeof(efs) - the memcpy to the uninitialized efs variable can be > > avoided, and the uninitialized variable would be returned to the > > attacker (16 bytes). > > > > This issue has been assigned CVE-2017-1000410 > > > > Cc: Marcel Holtmann > > Cc: Gustavo Padovan > > Cc: Johan Hedberg > > Cc: stable > > Signed-off-by: Ben Seri > > Signed-off-by: Greg Kroah-Hartman > > --- > > net/bluetooth/l2cap_core.c | 20 +++- > > 1 file changed, 11 insertions(+), 9 deletions(-) > > > > Marcel, for some reason this patch never got applied, despite lots of > > advance notice. Please, someone queue it up as it resolves the above > > very-well-reported issue. > > > > This patch is still not upstream or in -next. Given that we (ChromeOS) > are heavy Bluetooth users, I'll go ahead and apply it without waiting > any longer. For my understanding and for tracking purposes, it would > be useful to know why it is not being applied. Does anyone know ? I have no idea what is going on here, I'm going to throw it in my char-misc tree now, this really isn't acceptable at all. greg k-h
Re: [RFC 04/20] RDMA/irdma: Add driver framework definitions
On Sat, Oct 05, 2019 at 09:28:05AM +0300, Leon Romanovsky wrote:
> On Fri, Oct 04, 2019 at 05:46:15PM -0700, Jeff Kirsher wrote:
> > On Fri, 2019-10-04 at 23:45 +, Jason Gunthorpe wrote:
> > > On Fri, Oct 04, 2019 at 01:12:22PM -0700, Jeff Kirsher wrote:
> > >
> > > > > > + if (ldev->version.major != I40E_CLIENT_VERSION_MAJOR ||
> > > > > > + ldev->version.minor != I40E_CLIENT_VERSION_MINOR) {
> > > > > > + pr_err("version mismatch:\n");
> > > > > > + pr_err("expected major ver %d, caller specified
> > > > > > major
> > > > > > ver %d\n",
> > > > > > + I40E_CLIENT_VERSION_MAJOR, ldev-
> > > > > > >version.major);
> > > > > > + pr_err("expected minor ver %d, caller specified
> > > > > > minor
> > > > > > ver %d\n",
> > > > > > + I40E_CLIENT_VERSION_MINOR, ldev-
> > > > > > >version.minor);
> > > > > > + return -EINVAL;
> > > > > > + }
> > > > >
> > > > > This is can't be in upstream code, we don't support out-of-tree
> > > > > modules,
> > > > > everything else will have proper versions.
> > > >
> > > > Who is the "we" in this context?
> > >
> > > Upstream sensibility - if we start doing stuff like this then we will
> > > end up doing it everwhere.
> >
> > I see you cut out the part of my response about Linux distributions
> > disagreeing with this stance.
> >
> > >
> > > > you support out-of-tree drivers, they do exist and this code would
> > > > ensure that if a "out-of-tree" driver is loaded, the driver will do a
> > > > sanity check to ensure the RDMA driver will work.
> > >
> > > I don't see how this is any different from any of the other myriad of
> > > problems out of tree modules face.
> > >
> > > Someone providing out of tree modules has to provide enough parts of
> > > their driver so that it only consumes the stable ABI from the distro
> > > kernel.
> > >
> > > Pretty normal stuff really.
> >
> > Your right, if the dependency was reversed and the out-of-tree (OOT) driver
> > was dependent upon the RDMA driver, but in this case it is not. The LAN
> > driver does not "need" the RDMA driver to work. So the RDMA driver should
> > at least check that the LAN driver loaded has the required version to work.
>
> Not in upstream code, there is an expectation that kernel and modules are
> aligned.
s/expectation/requirement/
If you do not do that, all bets are off.
Distros can decide to do whatever they want with their kernels, but
that's not what we require upstream.
thanks,
greg k-h
Re: [PATCH 1/2] Revert commit 1b0a83ac04e383e3bed21332962b90710fcf2828
On Wed, Apr 29, 2020 at 09:03:32AM +, Badel, Laurent wrote:
> Description: This patch reverts commit 1b0a83ac04e3
> ("net: fec: add phy_reset_after_clk_enable() support")
> which produces undesirable behavior when PHY interrupts are enabled.
>
> Rationale: the SMSC LAN8720 (and possibly other chips) is known
> to require a reset after the external clock is enabled. Calls to
> phy_reset_after_clk_enable() in fec_main.c have been introduced in
> commit 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")
> to handle the chip reset after enabling the clock.
> However, this breaks when interrupts are enabled because
> the reset reverts the configuration of the PHY interrupt mask to default
> (in addition it also reverts the "energy detect" mode setting).
> As a result the driver does not receive the link status change
> and other notifications resulting in loss of connectivity.
>
> Proposed solution: revert commit 1b0a83ac04e3 and bring the reset
> before the PHY configuration by adding it to phy_init_hw() [phy_device.c].
>
> Test results: using an iMX28-EVK-based board, these 2 patches successfully
> restore network interface functionality when interrupts are enabled.
> Tested using both linux-5.4.23 and latest mainline (5.6.0) kernels.
>
> Fixes: 1b0a83ac04e383e3bed21332962b90710fcf2828 ("net: fec: add
> phy_reset_after_clk_enable() support")
Please read Documentation/process/submitting-patches.rst and the section
"2) Describe your changes" at the end, it says how to do lines like this
"properly".
thanks,
greg k-h
Re: [PATCH v2 1/6] Add ancillary bus support
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. > > 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 have use cases outside of RDMA and > netdev. Parav was ok with the current organization. The SOF folks > already have a proposed incorporation of it. The argument I am hearing > is that "this registration api seems hard for driver writers" when we > have several driver writers who have already taken a look and can make > it work. If you want to follow on with a simpler wrappers for your use > case, great, but I do not yet see anyone concurring with your opinion > that the current organization is irretrievably broken or too obscure > to use. That's kind of because I tuned out of this thread a long time ago :) I do agree with Leon that I think the current patch is not the correct way to do this the easiest, but don't have a competing proposal to show what I mean. Yet. Let's see what happens after 5.10-rc1 is out, it's too late now for any of this for this next merge window so we can not worry about it for a few weeks. thanks, greg k-h
Re: [RFC] debugfs: protect against rmmod while files are open
On Fri, Oct 09, 2020 at 10:56:16AM +, David Laight wrote: > From: Johannes Berg > > Sent: 09 October 2020 11:48 > > > > On Fri, 2020-10-09 at 12:41 +0200, Johannes Berg wrote: > > > > > If the fops doesn't have a release method, we don't even need > > > to keep a reference to the real_fops, we can just fops_put() > > > them already in debugfs remove, and a later full_proxy_release() > > > won't call anything anyway - this just crashed/UAFed because it > > > used real_fops, not because there was actually a (now invalid) > > > release() method. > > > > I actually implemented something a bit better than what I described - we > > never need a reference to the real_fops for the release method alone, > > and that means if the release method is in the kernel image, rather than > > a module, it can still be called. > > > > That together should reduce the ~117 places you changed in the large > > patchset to around a handful. > > Is there an equivalent problem for normal cdev opens > in any modules? What does cdev have to do with debugfs?
Re: [PATCH] net/packet: fix overflow in tpacket_rcv
On Fri, Sep 04, 2020 at 02:22:46PM +, Nuernberger, Stefan wrote:
> On Fri, 2020-09-04 at 16:16 +0200, Greg Kroah-Hartman wrote:
> > On Fri, Sep 04, 2020 at 03:30:52PM +0200, Stefan Nuernberger wrote:
> > >
> > > From: Or Cohen
> > >
> > > Using tp_reserve to calculate netoff can overflow as
> > > tp_reserve is unsigned int and netoff is unsigned short.
> > >
> > > This may lead to macoff receving a smaller value then
> > > sizeof(struct virtio_net_hdr), and if po->has_vnet_hdr
> > > is set, an out-of-bounds write will occur when
> > > calling virtio_net_hdr_from_skb.
> > >
> > > The bug is fixed by converting netoff to unsigned int
> > > and checking if it exceeds USHRT_MAX.
> > >
> > > This addresses CVE-2020-14386
> > >
> > > Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
> > > Signed-off-by: Or Cohen
> > > Signed-off-by: Eric Dumazet
> > >
> > > [ snu: backported to 4.9, changed tp_drops counting/locking ]
> > >
> > > Signed-off-by: Stefan Nuernberger
> > > CC: David Woodhouse
> > > CC: Amit Shah
> > > CC: sta...@vger.kernel.org
> > > ---
> > > net/packet/af_packet.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > What is the git commit id of this patch in Linus's tree?
> >
>
> Sorry, this isn't merged on Linus' tree yet. It's a heads up that the
> backport isn't straightforward.
Ok, please be more specific about this when sending patches out...
greg k-h
Re: [PATCH] rpc: properly check debugfs dentry before using it
On Tue, Feb 12, 2019 at 08:52:53PM +, Schumaker, Anna wrote:
> On Tue, 2019-02-12 at 19:27 +0100, Greg Kroah-Hartman wrote:
> > debugfs can now report an error code if something went wrong instead of
> > just NULL. So if the return value is to be used as a "real" dentry, it
> > needs to be checked if it is an error before dereferencing it.
> >
> > This is now happening because of ff9fb72bc077 ("debugfs: return error
> > values, not NULL"), but why debugfs files are not being created properly
> > is an older issue, probably one that has always been there and should
> > probably be looked at...
> >
> > Cc: "J. Bruce Fields"
> > Cc: Jeff Layton
> > Cc: Trond Myklebust
> > Cc: Anna Schumaker
> > Cc: linux-...@vger.kernel.org
> > Cc: netdev@vger.kernel.org
> > Reported-by: David Howells
> > Tested-by: David Howells
> > Signed-off-by: Greg Kroah-Hartman
> >
> > ---
> > net/sunrpc/debugfs.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > I can take this through my tree if people don't object, or it can go
> > through the NFS tree. It does need to get merged before 5.0-final
> > though.
>
> I'm planning another bugfixes pull for 5.0, so I can take this patch and send
> it
> with the others this week.
Wonderful, thanks for doing this, and sorry for the regression.
greg k-h
Re: [net-next v4 01/12] Implementation of Virtual Bus
On Thu, May 21, 2020 at 02:57:55PM +, Parav Pandit wrote:
> Hi Greg, Jason,
>
> On 5/20/2020 12:32 PM, Jeff Kirsher wrote:
> > From: Dave Ertman
> >
>
> > +static const
> > +struct virtbus_dev_id *virtbus_match_id(const struct virtbus_dev_id *id,
> > + struct virtbus_device *vdev)
> > +{
> > + while (id->name[0]) {
> > + if (!strcmp(vdev->match_name, id->name))
> > + return id;
>
> Should we have VID, DID based approach instead of _any_ string chosen by
> vendor drivers?
No, because:
> This will required central place to define the VID, DID of the vdev in
> vdev_ids.h to have unique ids.
That's not a good way to run things :)
Have the virtbus core create the "name", as it really doesn't matter
what it is, just that it is unique, right?
thanks,
greg k-h
Re: [EXTERNAL] Re: [PATCH 1/2] Revert commit 1b0a83ac04e383e3bed21332962b90710fcf2828
On Wed, Apr 29, 2020 at 11:22:58AM +, Badel, Laurent wrote: > Dear Greg, > > Thanks for your reply and sorry for my mistake. > Looks to me like the issue is the commit hash which should be 12 chars. > Does that mean I need to fix and resend the whole thing to everyone? Yes please, never force a maintainer to hand-edit a patch, they will not do so :) thanks, greg k-h
Re: [RFC 04/20] RDMA/irdma: Add driver framework definitions
On Thu, Sep 26, 2019 at 04:55:12PM +, Jason Gunthorpe wrote:
> On Thu, Sep 26, 2019 at 09:45:03AM -0700, Jeff Kirsher wrote:
> > +int i40iw_probe(struct platform_device *pdev)
> > +{
> > + struct i40e_peer_dev_platform_data *pdata =
> > + dev_get_platdata(&pdev->dev);
> > + struct i40e_info *ldev;
>
> I thought Greg already said not to use platform_device for this?
Yes I did, which is what I thought this whole "use MFD" was supposed to
solve. Why is a platform device still being used here?
thanks,
greg k-h
Re: [RFC 20/20] RDMA/i40iw: Mark i40iw as deprecated
On Thu, Sep 26, 2019 at 07:49:44PM +, Saleem, Shiraz wrote: > > Subject: Re: [RFC 20/20] RDMA/i40iw: Mark i40iw as deprecated > > > > On Thu, Sep 26, 2019 at 09:45:19AM -0700, Jeff Kirsher wrote: > > > From: Shiraz Saleem > > > > > > Mark i40iw as deprecated/obsolete. > > > > > > irdma is the replacement driver that supports X722. > > > > Can you simply delete old one and add MODULE_ALIAS() in new driver? > > > > Yes, but we thought typically driver has to be deprecated for a few cycles > before removing it. If you completely replace it with something that works the same, why keep the old one around at all? Unless you don't trust your new code? :) thanks, greg k-h
Re: [RFC 01/20] ice: Initialize and register multi-function device to provide RDMA
On Thu, Sep 26, 2019 at 11:39:22PM +, Nguyen, Anthony L wrote: > On Thu, 2019-09-26 at 20:05 +0200, Greg KH wrote: > > On Thu, Sep 26, 2019 at 09:45:00AM -0700, Jeff Kirsher wrote: > > > From: Tony Nguyen > > > > > > The RDMA block does not advertise on the PCI bus or any other bus. > > > > Huh? How do you "know" where it is then? Isn't is usually assigned > > to > > a PCI device? > > The RDMA block does not have its own PCI function so it must register > and interact with the ice driver. So the "ice driver" is the real thing controlling the pci device? How does it "know" about the RDMA block? thanks, greg k-h
Re: [RFC 15/20] RDMA/irdma: Add miscellaneous utility definitions
On Fri, Sep 27, 2019 at 02:28:20PM +, Saleem, Shiraz wrote: > > Subject: Re: [RFC 15/20] RDMA/irdma: Add miscellaneous utility definitions > > > > On Thu, Sep 26, 2019 at 07:49:33PM +, Saleem, Shiraz wrote: > > > > Subject: Re: [RFC 15/20] RDMA/irdma: Add miscellaneous utility > > > > definitions > > > > > > > > On Thu, Sep 26, 2019 at 09:45:14AM -0700, Jeff Kirsher wrote: > > > > > From: Mustafa Ismail > > > > > > > > > > Add miscellaneous utility functions and headers. > > > > > > > > > > Signed-off-by: Mustafa Ismail > > > > > Signed-off-by: Shiraz Saleem > > > > > --- > > > > > drivers/infiniband/hw/irdma/osdep.h | 108 ++ > > > > > drivers/infiniband/hw/irdma/protos.h | 96 ++ > > > > > drivers/infiniband/hw/irdma/status.h | 70 + > > > > > drivers/infiniband/hw/irdma/utils.c | 2333 > > > > > ++ > > > > > 4 files changed, 2607 insertions(+) create mode 100644 > > > > > drivers/infiniband/hw/irdma/osdep.h > > > > > create mode 100644 drivers/infiniband/hw/irdma/protos.h > > > > > create mode 100644 drivers/infiniband/hw/irdma/status.h > > > > > create mode 100644 drivers/infiniband/hw/irdma/utils.c > > > > > > > > > > diff --git a/drivers/infiniband/hw/irdma/osdep.h > > > > > b/drivers/infiniband/hw/irdma/osdep.h > > > > > new file mode 100644 > > > > > index ..5885b6fa413d > > > > > --- /dev/null > > > > > +++ b/drivers/infiniband/hw/irdma/osdep.h > > > > > @@ -0,0 +1,108 @@ > > > > > +/* SPDX-License-Identifier: GPL-2.0 or Linux-OpenIB */ > > > > > +/* Copyright (c) 2019, Intel Corporation. */ > > > > > + > > > > > +#ifndef IRDMA_OSDEP_H > > > > > +#define IRDMA_OSDEP_H > > > > > + > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +/* get readq/writeq support for 32 bit kernels, use the low-first > > > > > +version */ #include > > > > > + > > > > > +#define MAKEMASK(m, s) ((m) << (s)) > > > > > > > > It is a little bit over-macro. > > > > > > > > > > Why is this a problem? > > > We are not translating any basic kernel construct here. > > > > See BIT() definition. > > > OK. And? And you just re-created GENMASK(). Please use in-kernel definitions instead of creating your own. thanks, greg k-h
Re: linux kernel – 4.4.45 : VPN test failure
On Wed, Oct 25, 2017 at 12:49:09PM +, Nanjappa, Gangadhar wrote:
> Hi All,
> Using linux kernel – 4.4.45 (Blurry Fish Butt), VPN test fails. If I
> revert the attached five patches, VPN test passes. But I’m not
> supposed to revert the patches to get the test passed. I’m analyzing
> the patches, please help me to resolve this issue. If the below
> patches are present, in the VpnTest.java file that I’ve attached, the
> failure path is testAppDisallowed()--> checkNoTrafficOnVpn() -->
> checkUdpEcho("192.0.2.251", null) --> fail("Received unexpected
> reply");
4.4.45 is _very_ old, can you duplicate this on 4.4.94? Do you also
have this problem on 4.14-rc6?
thanks,
greg k-h
Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)
On Thu, May 19, 2016 at 12:59:09AM +, Dexuan Cui wrote: > > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > > Behalf > > Of Dexuan Cui > > Sent: Tuesday, May 17, 2016 10:46 > > To: David Miller > > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > > linux-ker...@vger.kernel.org; j...@perches.com; netdev@vger.kernel.org; > > a...@canonical.com; de...@linuxdriverproject.org; Haiyang Zhang > > > > Subject: RE: [PATCH v11 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock) > > > > > From: David Miller [mailto:da...@davemloft.net] > > > Sent: Monday, May 16, 2016 1:16 > > > To: Dexuan Cui > > > Cc: gre...@linuxfoundation.org; netdev@vger.kernel.org; linux- > > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > > > a...@canonical.com; jasow...@redhat.com; cav...@redhat.com; KY > > > Srinivasan ; Haiyang Zhang ; > > > j...@perches.com; vkuzn...@redhat.com > > > Subject: Re: [PATCH v11 net-next 0/1] introduce Hyper-V VM > > > Sockets(hv_sock) > > > > > > From: Dexuan Cui > > > Date: Sun, 15 May 2016 09:52:42 -0700 > > > > > > > Changes since v10 > > > > > > > > 1) add module params: send_ring_page, recv_ring_page. They can be used > > to > > > > enlarge the ringbuffer size to get better performance, e.g., > > > > # modprobe hv_sock recv_ring_page=16 send_ring_page=16 > > > > By default, recv_ring_page is 3 and send_ring_page is 2. > > > > > > > > 2) add module param max_socket_number (the default is 1024). > > > > A user can enlarge the number to create more than 1024 hv_sock sockets. > > > > By default, 1024 sockets take about 1024 * (3+2+1+1) * 4KB = 28M bytes. > > > > (Here 1+1 means 1 page for send/recv buffers per connection, > > > > respectively.) > > > > > > This is papering around my objections, and create module parameters which > > > I am fundamentally against. > > > > > > You're making the facility unusable by default, just to work around my > > > memory consumption concerns. > > > > > > What will end up happening is that everyone will simply increase the > > > values. > > > > > > You're not really addressing the core issue, and I will be ignoring you > > > future submissions of this change until you do. > > > > David, > > I am sorry I came across as ignoring your feedback; that was not my > > intention. > > The current host side design for this feature is such that each socket > > connection > > needs its own channel, which consists of > > > > 1.A ring buffer for host to guest communication > > 2.A ring buffer for guest to host communication > > > > The memory for the ring buffers has to be pinned down as this will be > > accessed > > both from interrupt level in Linux guest and from the host OS at any time. > > > > To address your concerns, I am planning to re-implement both the receive > > path > > and the send path so that no additional pinned memory will be needed. > > > > Receive Path: > > When the application does a read on the socket, we will dynamically allocate > > the buffer and perform the read operation on the incoming ring buffer. Since > > we will be in the process context, we can sleep here and will set the > > "GFP_KERNEL | __GFP_NOFAIL" flags. This buffer will be freed once the > > application consumes all the data. > > > > Send Path: > > On the send side, we will construct the payload to be sent directly on the > > outgoing ringbuffer. > > > > So, with these changes, the only memory that will be pinned down will be the > > memory for the ring buffers on a per-connection basis and this memory will > > be > > pinned down until the connection is torn down. > > > > Please let me know if this addresses your concerns. > > > > -- Dexuan > > Hi David, > Ping. Really appreciate your comment. Don't wait for people to respond to random design questions, go work on the code and figure out if it is workable or not yourself. Then post patches. We aren't responsible for your work, you are. greg k-h
Re: When will net-next merge with linux-next?
On Mon, Mar 14, 2016 at 06:09:41AM +, Dexuan Cui wrote: > Hi David, > I have a pending patch of the hv_sock driver, which should go into the > kernel through the net-next tree: > https://lkml.org/lkml/2016/2/14/7 > > The VMBus side's supporting patches of hv_sock have been in Greg's tree > and linux-next for more than 1 month, but they haven't been in net-next > yet, I suppose this is because of the releasing of 4.5. > > Now 4.5 is released. Will you merge with Greg's tree or linux-next? linux-next is a merge of all of the maintainer's trees, and it is rebased every day, it's impossible to merge that back into a maintainers tree, sorry. > I read netdev-FAQ.txt, but still don't have a clear idea about how things > work in my case. Try reading Documentation/development-process/ please. Things will get merged together into Linus's tree over the next 2 weeks as we ask him to pull our trees. thanks, greg k-h
Re: When will net-next merge with linux-next?
On Tue, Mar 15, 2016 at 11:11:34AM +, Dexuan Cui wrote: > I'm wondering whether (and when) step 2 will happen in the next 2 weeks, > that is, before the tag 4.6-rc1 is made. > If not, I guess I'll miss 4.6? You missed 4.6 as your patch was not in any of our trees a few days before 4.5 was released, sorry. greg k-h
Re: When will net-next merge with linux-next?
On Wed, Mar 16, 2016 at 01:58:50AM +, Dexuan Cui wrote: > > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > > Sent: Tuesday, March 15, 2016 23:06 > > To: Dexuan Cui > > Cc: David Miller ; netdev@vger.kernel.org; KY > > Srinivasan ; Haiyang Zhang > > Subject: Re: When will net-next merge with linux-next? > > > > On Tue, Mar 15, 2016 at 11:11:34AM +, Dexuan Cui wrote: > > > I'm wondering whether (and when) step 2 will happen in the next 2 weeks, > > > that is, before the tag 4.6-rc1 is made. > > > If not, I guess I'll miss 4.6? > > > > You missed 4.6 as your patch was not in any of our trees a few days > > before 4.5 was released, sorry. > > > > greg k-h > Hi Greg, > Thanks for the reply! > > My patch has to go in net-next first, but even today's mainline and net-next > haven't had the supporting patches in the VMBus driver, so I can't post my > patch to net-next even today -- it seems it's doomed to need 2 major > release cycles to push a feature that makes changes to 2 subsystems? :-( Usually, yes, unless you talk to us ahead of time so we can coordinate, or have one of the patches go through a different tree (i.e. all in one tree.). Just wait until 4.6-rc1 is out and all will be fine. greg k-h
Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t
On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote: > > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote: > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid accidental > > > refcounter overflows that might lead to use-after-free > > > situations. > > > > Looks good. Let me know how do you want to route the patch to upstream. > > Greg, you previously mentioned that driver's conversions can go via your > tree. Does this still apply? > Or should I be asking maintainers to merge these patches via their trees? You should ask them to take them through their trees, if they have them. I'll be glad to scoop up all of the remaining ones that get missed, or for subsystems that do not have trees. thanks, greg k-h
Re: [PATCH net] hyper-v: Add myself as additional MAINTAINER
On Thu, Jan 05, 2017 at 05:43:04PM +, KY Srinivasan wrote: > > > > -Original Message- > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Thursday, January 5, 2017 9:36 AM > > To: da...@davemloft.net; KY Srinivasan > > Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org; > > gre...@linuxfoundation.org; Stephen Hemminger > > > > Subject: [PATCH net] hyper-v: Add myself as additional MAINTAINER > > > > Update the Hyper-V MAINTAINERS to include myself. > > > > Signed-off-by: Stephen Hemminger > > Acked-by: K. Y. Srinivasan Thanks, will go queue this up now. greg k-h
Re: [PATCH net] hyper-v: Add myself as additional MAINTAINER
On Thu, Jan 05, 2017 at 07:08:23PM +, KY Srinivasan wrote: > > > > -Original Message- > > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > > Sent: Thursday, January 5, 2017 10:29 AM > > To: KY Srinivasan > > Cc: Stephen Hemminger ; > > da...@davemloft.net; netdev@vger.kernel.org; linux- > > ker...@vger.kernel.org; Stephen Hemminger > > Subject: Re: [PATCH net] hyper-v: Add myself as additional MAINTAINER > > > > On Thu, Jan 05, 2017 at 05:43:04PM +, KY Srinivasan wrote: > > > > > > > > > > -Original Message- > > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > > Sent: Thursday, January 5, 2017 9:36 AM > > > > To: da...@davemloft.net; KY Srinivasan > > > > Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org; > > > > gre...@linuxfoundation.org; Stephen Hemminger > > > > > > > > Subject: [PATCH net] hyper-v: Add myself as additional MAINTAINER > > > > > > > > Update the Hyper-V MAINTAINERS to include myself. > > > > > > > > Signed-off-by: Stephen Hemminger > > > > > > Acked-by: K. Y. Srinivasan > > > > Thanks, will go queue this up now. > > Thanks Greg. On a different note, there are a bunch of Hyper-V specific > patches that have been submitted over the last month or so that have not > been committed. Should I resend them. Nope, they are still in my mbox, I'm just going through stuff that has to be in 4.10-final at the moment, give me another week or so to catch up on all the new stuff for 4.11-rc1. thanks, greg k-h
Re: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Fri, Sep 30, 2016 at 08:37:36AM +, Levy, Amir (Jer) wrote: > On Fri, Sep 30 2016, 09:40 AM, David Miller wrote: > > From: Greg KH > > Date: Fri, 30 Sep 2016 08:30:05 +0200 > > > > > On Fri, Sep 30, 2016 at 01:55:55AM -0400, David Miller wrote: > > >> From: Amir Levy > > >> Date: Wed, 28 Sep 2016 17:44:22 +0300 > > >> > > >> > This driver enables Thunderbolt Networking on non-Apple platforms > > >> > running Linux. > > >> > > >> Greg, any idea where this should get merged once fully vetted? I can > > >> take it through the net-next tree, but I'm fine with another more > > >> appropriate tree taking it as well. > > > > > > I am supposed to be taking thunderbolt patches, but if this really is > > > a network driver, it should go under drivers/net/ somewhere. It needs > > > more review though, it's not ready to go through anyone's tree just > > > yet :) > > > > > > I'll let the thunderbolt maintainer go through it first before asking > > > for a netdev review. > > > > Ok, thanks Greg. > > Greg, David, > Andreas replied to similar request on patch v6: > "This driver is independent from mine. It uses an interface provided > by the firmware which is not present on Apple hardware and with which > I am not familiar (also it does networking, not pci with which I am > also not familiar). So I cannot comment on the driver itself. I don't > mind a second driver, if that is what you are asking." Yes, but I still need an ack from the thunderbolt maintainer that you aren't doing anything foolish with that interface before I can take the code. > Note that Thunderbolt Networking is the first feature we would like to > submit, but the next features aren't related to network, but more to > Thunderbolt functionality. If this really is a real network device, it should probably live in drivers/net/ like other network drivers. > This is the reason I created the directory thunderbolt/icm, since the > next features requires ICM to be enabled as well. As long as you have ICM split out so that other drivers can use it, it should be fine, no matter where in the tree it lives, right? > I also followed the firewire as example that includes net.c (in > drivers/firewire directory) along with other firewire functionality. That's the old-style of placing files. We have moved the USB network drivers out of drivers/usb/ a while ago. The current thought is to group drivers of specific types, not busses, together wherever possible, as that is usually the majority of the logic in the driver (i.e. a USB network driver has more network-driver specific logic than USB-specific logic.) Hope this helps explain things. I'll get to your patches next week, they are in my queue at the moment, but have conferences to deal with at the moment. Don't let my delay stop you from working on further "ICM" drivers if needed, you can always send new series of patches that build on this one when you have it ready. thanks, greg k-h
Re: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Sun, Nov 20, 2016 at 06:30:19AM +, Levy, Amir (Jer) wrote: > On Fri, Nov 18 2016, 12:07 PM, gre...@linuxfoundation.org wrote: > > On Fri, Nov 18, 2016 at 08:48:36AM +, Levy, Amir (Jer) wrote: > > > > BTW, it is quite a shame that the Thunderbolt firmware version can't > > > > be read from Linux. > > > > > > > > > > This is WIP, once this patch will be upstream, we will be able to > > > focus more on aligning Linux with the Thunderbolt features that we have > > for windows. > > > > Why is this patch somehow holding that work back? You aren't just sitting > > around waiting for people to review this and not doing anything else, right? > > Is there some basic building block in these patches that your firmware > > download code is going to rely on? > > > > confused, > > > > greg k-h > > All the Thunderbolt SW features (including networking and FW update) depend > on the communication with FW, which is patch 3/8 in the series. > The patch also sets up a generic netlink for user space communication. It's that "generic netlink" connection that I really want a whole lot of revewers to read over as it's very unusual and "different" from all other driver subsystems. thanks, greg k-h
Re: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Fri, Nov 18, 2016 at 08:48:36AM +, Levy, Amir (Jer) wrote: > > BTW, it is quite a shame that the Thunderbolt firmware version can't > > be read from Linux. > > > > This is WIP, once this patch will be upstream, we will be able to focus more > on aligning Linux with the Thunderbolt features that we have for windows. Why is this patch somehow holding that work back? You aren't just sitting around waiting for people to review this and not doing anything else, right? Is there some basic building block in these patches that your firmware download code is going to rely on? confused, greg k-h
