Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1208167 > unrolled thread

[PATCH] mm: Change global memory state symbols to GPL-only

Back to article view | Back to linux.kernel

Contents

  [PATCH] mm: Change global memory state symbols to GPL-only Ben Hutchings <ben@decadent.org.uk> - 2015-08-16 01:50 +0200
    Re: [PATCH] mm: Change global memory state symbols to GPL-only Michal Hocko <mhocko@kernel.org> - 2015-08-17 16:00 +0200
      Re: [PATCH] mm: Change global memory state symbols to GPL-only Ben Hutchings <ben@decadent.org.uk> - 2015-08-17 17:00 +0200
        Re: [PATCH] mm: Change global memory state symbols to GPL-only Michal Hocko <mhocko@kernel.org> - 2015-08-17 17:20 +0200
          Re: [PATCH] mm: Change global memory state symbols to GPL-only Ben Hutchings <ben@decadent.org.uk> - 2015-08-17 19:00 +0200

#1208167 — [PATCH] mm: Change global memory state symbols to GPL-only

[Multipart message — attachments visible in raw view] — view raw

Proprietary modules should not be able to touch vm_stat or participate
in shrinking.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 mm/vmscan.c | 4 ++--
 mm/vmstat.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8286938..e6e7449 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -247,7 +247,7 @@ int register_shrinker(struct shrinker *shrinker)
 	up_write(&shrinker_rwsem);
 	return 0;
 }
-EXPORT_SYMBOL(register_shrinker);
+EXPORT_SYMBOL_GPL(register_shrinker);
 
 /*
  * Remove one
@@ -259,7 +259,7 @@ void unregister_shrinker(struct shrinker *shrinker)
 	up_write(&shrinker_rwsem);
 	kfree(shrinker->nr_deferred);
 }
-EXPORT_SYMBOL(unregister_shrinker);
+EXPORT_SYMBOL_GPL(unregister_shrinker);
 
 #define SHRINK_BATCH 128
 
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 4f5cd97..6d3f8f4 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -87,7 +87,7 @@ void vm_events_fold_cpu(int cpu)
  * vm_stat contains the global counters
  */
 atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS] __cacheline_aligned_in_smp;
-EXPORT_SYMBOL(vm_stat);
+EXPORT_SYMBOL_GPL(vm_stat);
 
 #ifdef CONFIG_SMP
 
-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

[toc] | [next] | [standalone]

#1208606

On Sun 16-08-15 01:42:27, Ben Hutchings wrote:
> Proprietary modules should not be able to touch vm_stat or participate
> in shrinking.

How does the external and !GPL fs does slab reclaim? Those are essential
for the proper memory balancing.

You are probably right about vm_stat though. Those counters should be
out of those modules.

> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
>  mm/vmscan.c | 4 ++--
>  mm/vmstat.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 8286938..e6e7449 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -247,7 +247,7 @@ int register_shrinker(struct shrinker *shrinker)
>  	up_write(&shrinker_rwsem);
>  	return 0;
>  }
> -EXPORT_SYMBOL(register_shrinker);
> +EXPORT_SYMBOL_GPL(register_shrinker);
>  
>  /*
>   * Remove one
> @@ -259,7 +259,7 @@ void unregister_shrinker(struct shrinker *shrinker)
>  	up_write(&shrinker_rwsem);
>  	kfree(shrinker->nr_deferred);
>  }
> -EXPORT_SYMBOL(unregister_shrinker);
> +EXPORT_SYMBOL_GPL(unregister_shrinker);
>  
>  #define SHRINK_BATCH 128
>  
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index 4f5cd97..6d3f8f4 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -87,7 +87,7 @@ void vm_events_fold_cpu(int cpu)
>   * vm_stat contains the global counters
>   */
>  atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS] __cacheline_aligned_in_smp;
> -EXPORT_SYMBOL(vm_stat);
> +EXPORT_SYMBOL_GPL(vm_stat);
>  
>  #ifdef CONFIG_SMP
>  
> -- 
> Ben Hutchings
> [W]e found...that it wasn't as easy to get programs right as we had thought.
> ... I realized that a large part of my life from then on was going to be spent
> in finding mistakes in my own programs. - Maurice Wilkes, 1949
> 



-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1208631

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2015-08-17 at 15:54 +0200, Michal Hocko wrote:
> On Sun 16-08-15 01:42:27, Ben Hutchings wrote:
> > Proprietary modules should not be able to touch vm_stat or participate
> > in shrinking.
> 
> How does the external and !GPL fs does slab reclaim? Those are essential
> for the proper memory balancing.

If they know how to do shrinking on Linux then they are probably
derivative works of Linux.

Ben.

> You are probably right about vm_stat though. Those counters should be
> out of those modules.
> 
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > ---
> >  mm/vmscan.c | 4 ++--
> >  mm/vmstat.c | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 8286938..e6e7449 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -247,7 +247,7 @@ int register_shrinker(struct shrinker *shrinker)
> >  > > 	> > up_write(&shrinker_rwsem);
> >  > > 	> > return 0;
> >  }
> > -EXPORT_SYMBOL(register_shrinker);
> > +EXPORT_SYMBOL_GPL(register_shrinker);
> >  
> >  /*
> >   * Remove one
> > @@ -259,7 +259,7 @@ void unregister_shrinker(struct shrinker *shrinker)
> >  > > 	> > up_write(&shrinker_rwsem);
> >  > > 	> > kfree(shrinker->nr_deferred);
> >  }
> > -EXPORT_SYMBOL(unregister_shrinker);
> > +EXPORT_SYMBOL_GPL(unregister_shrinker);
> >  
> >  #define SHRINK_BATCH 128
> >  
> > diff --git a/mm/vmstat.c b/mm/vmstat.c
> > index 4f5cd97..6d3f8f4 100644
> > --- a/mm/vmstat.c
> > +++ b/mm/vmstat.c
> > @@ -87,7 +87,7 @@ void vm_events_fold_cpu(int cpu)
> >   * vm_stat contains the global counters
> >   */
> >  atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS] __cacheline_aligned_in_smp;
> > -EXPORT_SYMBOL(vm_stat);
> > +EXPORT_SYMBOL_GPL(vm_stat);
> >  
> >  #ifdef CONFIG_SMP
> >  
> > -- 
> > Ben Hutchings
> > [W]e found...that it wasn't as easy to get programs right as we had thought.
> > ... I realized that a large part of my life from then on was going to be spent
> > in finding mistakes in my own programs. - Maurice Wilkes, 1949
> > 
> 
> 
> 
-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

[toc] | [prev] | [next] | [standalone]

#1208643

On Mon 17-08-15 16:56:32, Ben Hutchings wrote:
> On Mon, 2015-08-17 at 15:54 +0200, Michal Hocko wrote:
> > On Sun 16-08-15 01:42:27, Ben Hutchings wrote:
> > > Proprietary modules should not be able to touch vm_stat or participate
> > > in shrinking.
> > 
> > How does the external and !GPL fs does slab reclaim? Those are essential
> > for the proper memory balancing.
> 
> If they know how to do shrinking on Linux then they are probably
> derivative works of Linux.

I am not sure I understand. They are shrinking their internal cached
objects and that is hardly a derivative work. The shrinker API is only
meant to let them know _when_ this should happen and the interface is
a pretty much simple callback API.

I do not want to defend a proprietary code here but this sounds like an
obstruction for those modules which will lead into a worse code in the
end because they should somehow manage the cache and it is much better
when the core (MM) tells them when it makes sense rather than external
heuristics.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1208719

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2015-08-17 at 17:11 +0200, Michal Hocko wrote:
> On Mon 17-08-15 16:56:32, Ben Hutchings wrote:
> > On Mon, 2015-08-17 at 15:54 +0200, Michal Hocko wrote:
> > > On Sun 16-08-15 01:42:27, Ben Hutchings wrote:
> > > > Proprietary modules should not be able to touch vm_stat or participate
> > > > in shrinking.
> > > 
> > > How does the external and !GPL fs does slab reclaim? Those are essential
> > > for the proper memory balancing.
> > 
> > If they know how to do shrinking on Linux then they are probably
> > derivative works of Linux.
> 
> I am not sure I understand. They are shrinking their internal cached
> objects and that is hardly a derivative work. The shrinker API is only
> meant to let them know _when_ this should happen and the interface is
> a pretty much simple callback API.

It is a Linux-specific API and I don't think other kernels provide
something similar to loadable modules.  It enables a module to turn a
large part of the system RAM into a cache and have the MM effectively
tell it the correct size of that cache, thus tightly integrating with
global memory management.

It seemed to me that this met the test for 'should this be
EXPORT_SYMBOL_GPL'.

> I do not want to defend a proprietary code here but this sounds like an
> obstruction for those modules which will lead into a worse code in the
> end because they should somehow manage the cache and it is much better
> when the core (MM) tells them when it makes sense rather than external
> heuristics.

Yes, that's the idea, proprietary code should not be helped in this
way.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web