Re: cleanup the walk_page_range interface v2

On Wed, Aug 28, 2019 at 04:19:52PM +0200, Christoph Hellwig wrote: > Hi all, > > this series is based on a patch from Linus to split the callbacks > passed to walk_page_range and walk_page_vma into a separate structure > that can be marked const, with various cleanups from me on top. > > This ser

Re: cleanup the walk_page_range interface

On 28/08/2019 00:36, Jason Gunthorpe wrote: > On Tue, Aug 27, 2019 at 04:34:31PM -0700, Andrew Morton wrote: >> On Tue, 27 Aug 2019 01:34:13 + Jason Gunthorpe wrote: >> >>> On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote: On Fri, Aug 23, 2019 at 01:43:12PM +, Jason G

Re: cleanup the walk_page_range interface

On Tue, Aug 27, 2019 at 11:36:26PM +, Jason Gunthorpe wrote: > Okay, I'll get it on a branch and merge it toward hmm.git tomorrow I was planning to resend it with the rebase, especially as the build bot picked a build error in task_mmu.c where we were missing a stub for an unusual configuratio

Re: cleanup the walk_page_range interface

On Tue, Aug 27, 2019 at 04:34:31PM -0700, Andrew Morton wrote: > On Tue, 27 Aug 2019 01:34:13 + Jason Gunthorpe wrote: > > > On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote: > > > On Fri, Aug 23, 2019 at 01:43:12PM +, Jason Gunthorpe wrote: > > > > > So what is the plan

Re: cleanup the walk_page_range interface

On Tue, 27 Aug 2019 01:34:13 + Jason Gunthorpe wrote: > On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote: > > On Fri, Aug 23, 2019 at 01:43:12PM +, Jason Gunthorpe wrote: > > > > So what is the plan forward? Probably a little late for 5.3, > > > > so queue it up in -mm f

Re: cleanup the walk_page_range interface

On Sat, Aug 24, 2019 at 03:26:55PM -0700, Christoph Hellwig wrote: > On Fri, Aug 23, 2019 at 01:43:12PM +, Jason Gunthorpe wrote: > > > So what is the plan forward? Probably a little late for 5.3, > > > so queue it up in -mm for 5.4 and deal with the conflicts in at least > > > hmm? Queue it

Re: cleanup the walk_page_range interface

On Fri, Aug 23, 2019 at 01:43:12PM +, Jason Gunthorpe wrote: > > So what is the plan forward? Probably a little late for 5.3, > > so queue it up in -mm for 5.4 and deal with the conflicts in at least > > hmm? Queue it up in the hmm tree even if it doesn't 100% fit? > > Did we make a decision

Re: cleanup the walk_page_range interface

On 23/08/2019 14:43, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 11:27:51PM -0700, Christoph Hellwig wrote: >> On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote: >>> On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig wrote: this series is based on a patch from Linus to sp

Re: cleanup the walk_page_range interface

On Thu, Aug 15, 2019 at 11:27:51PM -0700, Christoph Hellwig wrote: > On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote: > > On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig wrote: > > > > > > this series is based on a patch from Linus to split the callbacks > > > passed to walk_page_r

Re: cleanup the walk_page_range interface

On Fri, Aug 16, 2019 at 11:41 PM Stephen Rothwell wrote: > > I certainly prefer that method of API change :-) > (see the current "keys: Replace uid/gid/perm permissions checking with > an ACL" in linux-next Side note: I will *not* be pulling that again. It was broken last time, and without more

Re: cleanup the walk_page_range interface

Hi Christoph, On Sat, 17 Aug 2019 08:43:01 +0200 Christoph Hellwig wrote: > > On Sat, Aug 17, 2019 at 04:41:24PM +1000, Stephen Rothwell wrote: > > I certainly prefer that method of API change :-) > > (see the current "keys: Replace uid/gid/perm permissions checking with > > an ACL" in linux-next

Re: cleanup the walk_page_range interface

On Sat, Aug 17, 2019 at 04:41:24PM +1000, Stephen Rothwell wrote: > I certainly prefer that method of API change :-) > (see the current "keys: Replace uid/gid/perm permissions checking with > an ACL" in linux-next and the (currently) three merge fixup patches I > am carrying. Its not bad when peop

Re: cleanup the walk_page_range interface

Hi all, On Fri, 16 Aug 2019 14:06:23 -0700 Andrew Morton wrote: > > On Fri, 16 Aug 2019 14:32:58 +0200 Christoph Hellwig wrote: > > > On Fri, Aug 16, 2019 at 11:57:40AM +, Jason Gunthorpe wrote: > > > Are there conflicts with trees other than hmm? > > > > > > We can put it on a topic br

Re: cleanup the walk_page_range interface

On Fri, 16 Aug 2019 14:32:58 +0200 Christoph Hellwig wrote: > On Fri, Aug 16, 2019 at 11:57:40AM +, Jason Gunthorpe wrote: > > Are there conflicts with trees other than hmm? > > > > We can put it on a topic branch and merge to hmm to resolve. If hmm > > has problems then send the topic on it

Re: cleanup the walk_page_range interface

On Fri, Aug 16, 2019 at 5:33 AM Christoph Hellwig wrote: > > I see two new walk_page_range user in linux-next related to MADV_COLD > support (which probably really should use walk_range_vma), and then > there is the series from Steven, which hasn't been merged yet. It does sound like this might a

Re: cleanup the walk_page_range interface

On Fri, Aug 16, 2019 at 11:57:40AM +, Jason Gunthorpe wrote: > Are there conflicts with trees other than hmm? > > We can put it on a topic branch and merge to hmm to resolve. If hmm > has problems then send the topic on its own? I see two new walk_page_range user in linux-next related to MADV

Re: cleanup the walk_page_range interface

On Thu, Aug 15, 2019 at 11:27:51PM -0700, Christoph Hellwig wrote: > On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote: > > On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig wrote: > > > > > > this series is based on a patch from Linus to split the callbacks > > > passed to walk_page_r

Re: cleanup the walk_page_range interface

On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote: > On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig wrote: > > > > this series is based on a patch from Linus to split the callbacks > > passed to walk_page_range and walk_page_vma into a separate structure > > that can be marked const

Re: cleanup the walk_page_range interface

On Thu, Aug 08, 2019 at 11:56:32PM +0200, Christoph Hellwig wrote: > On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote: > > > Note that both Thomas and Steven have series touching this area pending, > > > and there are a couple consumer in flux too - the hmm tree already > > > conflict

Re: cleanup the walk_page_range interface

On Fri, Aug 09, 2019 at 12:21:24AM +0200, Thomas Hellstrom wrote: > On 8/8/19 11:56 PM, Christoph Hellwig wrote: >> On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote: Note that both Thomas and Steven have series touching this area pending, and there are a couple consumer in f

Re: cleanup the walk_page_range interface

On 8/8/19 11:56 PM, Christoph Hellwig wrote: On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote: Note that both Thomas and Steven have series touching this area pending, and there are a couple consumer in flux too - the hmm tree already conflicts with this series, and I have potentia

Re: cleanup the walk_page_range interface

On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote: > > Note that both Thomas and Steven have series touching this area pending, > > and there are a couple consumer in flux too - the hmm tree already > > conflicts with this series, and I have potential dma changes on top of > > the cons

Re: cleanup the walk_page_range interface

On Thu, Aug 8, 2019 at 8:42 AM Christoph Hellwig wrote: > > this series is based on a patch from Linus to split the callbacks > passed to walk_page_range and walk_page_vma into a separate structure > that can be marked const, with various cleanups from me on top. The whole series looks good to me

Re: Cleanup of -Wunused-const-variable in drivers/usb/host/xhci-tegra.c

On Thu, Jun 13, 2019 at 11:38:38AM -0700, Nathan Huckleberry wrote: > Hey all, > > I'm looking into cleaning up ignored warnings in the kernel so we can > remove compiler flags to ignore warnings. > > There's an unused variable ('mbox_cmd_name') in xhci-tegra.c. Looks > like it was intended for l

Re: Cleanup of -Wunused-const-variable in drivers/usb/host/xhci-tegra.c

On Thu, Jun 13, 2019 at 11:38:38AM -0700, Nathan Huckleberry wrote: > Hey all, > > I'm looking into cleaning up ignored warnings in the kernel so we can > remove compiler flags to ignore warnings. > > There's an unused variable ('mbox_cmd_name') in xhci-tegra.c. Looks > like it was intended for l

Re: cleanup and refactor BLOCK_PC mapping helpers V2

On 05.02.2015 09:28, Jens Axboe wrote: > On 02/02/2015 06:19 AM, Christoph Hellwig wrote: > >Jens, do these patches look fine to you? Any chance to get them into > >the tree for the 3.20 merge window? > > Yes, I think they look fine. I'll throw them into the testing mix and merge > them for 3.20.

Re: cleanup and refactor BLOCK_PC mapping helpers V2

On 02/02/2015 06:19 AM, Christoph Hellwig wrote: On Sun, Jan 25, 2015 at 06:29:11PM +0800, Ming Lei wrote: Looks all are nice cleanup: Reviewed-by: Ming Lei Also patches passed xfstests(check -g auto) against v3.19-rc4_next-20150115. Jens, do these patches look fine to you? Any chance to g

Re: cleanup and refactor BLOCK_PC mapping helpers V2

On Mon, Feb 02, 2015 at 02:19:09PM +0100, Christoph Hellwig wrote: > On Sun, Jan 25, 2015 at 06:29:11PM +0800, Ming Lei wrote: > > Looks all are nice cleanup: > > > > Reviewed-by: Ming Lei > > > > Also patches passed xfstests(check -g auto) against v3.19-rc4_next-20150115. > > Jens, do these patc

Re: cleanup and refactor BLOCK_PC mapping helpers V2

On Sun, Jan 25, 2015 at 06:29:11PM +0800, Ming Lei wrote: > Looks all are nice cleanup: > > Reviewed-by: Ming Lei > > Also patches passed xfstests(check -g auto) against v3.19-rc4_next-20150115. Jens, do these patches look fine to you? Any chance to get them into the tree for the 3.20 merge wind

Re: cleanup and refactor BLOCK_PC mapping helpers V2

On 01/18/2015 11:16 PM, Christoph Hellwig wrote: This series is based on the first two patches from the reent series that Dongsu Park recently sent, and refactors and cleanups up various aspect of our BLOCK_PC mapping helpers. Changes since V1: - keep a separate blk_rq_map_user for now, it c

Re: Cleanup of Kernel Bugzilla

On Sun, Jun 29, 2014 at 10:09:35PM -0400, Nick Krause wrote: > If that is true , it may be a good idea to get me or someone to write > a text file like maintainers that > is used to keep track of open bugs by subsystem in the main kernel directory. Kindly please reread my message below, because I'

Re: Cleanup of Kernel Bugzilla

If that is true , it may be a good idea to get me or someone to write a text file like maintainers that is used to keep track of open bugs by subsystem in the main kernel directory. Cheers Nick On Sun, Jun 29, 2014 at 5:32 PM, Theodore Ts'o wrote: > On Sun, Jun 29, 2014 at 09:21:46AM +0200, Leven

Re: Cleanup of Kernel Bugzilla

On Sun, Jun 29, 2014 at 09:21:46AM +0200, Levente Kurusa wrote: > > I think that is because they are relatively young and they are generally > used for one direct purpose. The kernel has to make sure it works in a lot > of different situations and hence a lot of different bugs arise. There are a

Re: Cleanup of Kernel Bugzilla

Hi, [Why was stable on Cc?] On 06/29/2014 08:33 AM, Gideon D'souza wrote: Why do you want an up to date list of kernel bugs? Even I'm a newbie and was looking for the same thing. I read eventually somewhere that bugzilla isn't maintained by kernel devs so I entirely gave up trying to find a b

Re: Cleanup of Kernel Bugzilla

>Why do you want an up to date list of kernel bugs? Even I'm a newbie and was looking for the same thing. I read eventually somewhere that bugzilla isn't maintained by kernel devs so I entirely gave up trying to find a bug to adopt. Many open source projects I've worked on (web frameworks mostly)

Re: Cleanup of Kernel Bugzilla

Thanks that's fine , I am new to kernel work , so a list of bugs would be very helpful in my helping out with debugging. Cheers Nick On Sat, Jun 28, 2014 at 3:18 PM, One Thousand Gnomes wrote: > On Fri, 27 Jun 2014 22:45:47 -0400 > Nick Krause wrote: > >> Do any of you use the kernel Bugzilla?

Re: Cleanup of Kernel Bugzilla

On Fri, 27 Jun 2014 22:45:47 -0400 Nick Krause wrote: > Do any of you use the kernel Bugzilla? If you do I was wondering if we > can clean it up. Developers are generally focussed on fixing bugs. Also the way bugzilla works a lot of developers don't close the bugs and the originators never get a

Re: Cleanup of Kernel Bugzilla

On Sat, Jun 28, 2014 at 12:06:15PM -0400, Nick Krause wrote: > Do all of you guys even care about cleaning up bugs? If > you do it would be great if I get a reply to where I can get > a up to date list of kernel bugs. We care about fixing bugs. Most kernel devs don't really care about maintaining

Re: Cleanup of Kernel Bugzilla

On Fri, Jun 27, 2014 at 10:45:47PM -0400, Nick Krause wrote: > Do any of you use the kernel Bugzilla? If you do I was wondering if we > can clean it up. > Otherwise I was wondering were I can get an accurate list of open > bugs in the newest > kernels. Some subsystem maintainers use the kernel bu

Re: Cleanup of Kernel Bugzilla

Do all of you guys even care about cleaning up bugs? If you do it would be great if I get a reply to where I can get a up to date list of kernel bugs. Cheers Nick On Fri, Jun 27, 2014 at 10:45 PM, Nick Krause wrote: > Do any of you use the kernel Bugzilla? If you do I was wondering if we > can cl

Re: Cleanup of Kernel Bugzilla

Do any of you use the kernel Bugzilla? If you do I was wondering if we can clean it up. Otherwise I was wondering were I can get an accurate list of open bugs in the newest kernels. Cheers Nick On Fri, Jun 27, 2014 at 2:11 PM, Nick Krause wrote: > Hey fellow developers > I seem to be finding lo

Re: Cleanup console loglevels

On 05/16/2014 10:51 AM, Borislav Petkov wrote: > On Fri, May 16, 2014 at 07:49:21PM +0200, Borislav Petkov wrote: >> Hi, >> >> so I was staring at >> >> 12544697f12e ("x86_64: be less annoying on boot, v2") >> >> and how naked numbers mean sh*t and how I have to grep sources to find >> out what thi

Re: Cleanup console loglevels

On Fri, May 16, 2014 at 07:49:21PM +0200, Borislav Petkov wrote: > Hi, > > so I was staring at > > 12544697f12e ("x86_64: be less annoying on boot, v2") > > and how naked numbers mean sh*t and how I have to grep sources to find > out what this 10 thing means. So how about the following cleanup?

RE: cleanup

Your Mailbox Has Exceeded It Storage Limit As Set By Your Administrator, And You Will Not Be Able To Receive New Mails until You Re-Validate It. To Re-Validate or If it does not work then copy and past the link. Thank you © 2013 by Intel

Re: Cleanup kbuild for aic7xxx

"Justin T. Gibbs" wrote: > > >> >Users don't have to manually select "rebuild firmware". They can > >> >rely on the generated files already in the aic7xxx directory. This > >> >is why the option defaults to off. > > > >For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have > >h

Re: Cleanup kbuild for aic7xxx

>> >Users don't have to manually select "rebuild firmware". They can >> >rely on the generated files already in the aic7xxx directory. This >> >is why the option defaults to off. > >For the SGI patched kernels based on either 2.4.5 or 2.4.6-pre1, I have >had to manually select this for a 7892 co

Re: Cleanup kbuild for aic7xxx

"J . A . Magallon" wrote: > > On 20010623 Keith Owens wrote: > > > >>What again are you trying to fix? It looks to me like you are simply > >>trying to make it harder for people actually working on the aic7xxx > >>driver to have proper dependencies. > > > >The patch still works for anybody chang

Re: Cleanup kbuild for aic7xxx

Keith Owens wrote: > > On Fri, 22 Jun 2001 13:39:45 -0600, > "Justin T. Gibbs" <[EMAIL PROTECTED]> wrote: > >>The existing build process for aic7xxx on Linux has several problems. > >> > >>* Users have to manually select "rebuild firmware". Relying on users > >> to perform any action other than

Re: Cleanup (PCI API and general) of drivers/net/rcpci.c (240t13p3)

On Thu, Dec 21, 2000 at 10:46:52PM +, Alan Cox wrote: > > o The driver currently allocates irqs during its initialization > > instead of postponing it until it is opened for use. Is there > > a reason for this? > > Shouldnt be - its an I2O network interface with some extra bits for > the

Re: Cleanup (PCI API and general) of drivers/net/rcpci.c (240t13p3)

> Questions for the maintainers, should they read this (does anyone > know their email addresses?) (others should feel free to chip in): I've not heard from them for a long time > o The driver currently allocates irqs during its initialization > instead of postponing it until it is opened for