On Thu, Apr 08, 2021 at 10:55:53AM +0200, Greg KH wrote:
> Module removal is not a "normal" operation that can be triggered by a
> system automatically without a user asking for it. As someone reminded
> me on IRC, we used to do this "automatically" for many problematic
> drivers years ago for
On Thu, Apr 08, 2021 at 10:55:53AM +0200, Greg KH wrote:
> So to add crazy complexity to the kernel,
I agree that this can be tricky. However, driver developers are going to
open code this either way. The problem with that as well, and one of my
own reasons for striving for at least *trying* for
On Thu, Apr 08, 2021 at 08:18:21AM +0200, Greg KH wrote:
> On Wed, Apr 07, 2021 at 03:17:46PM -0500, Josh Poimboeuf wrote:
> > On Fri, Apr 02, 2021 at 09:54:12AM +0200, Greg KH wrote:
> > > On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> > > > As for the syfs deadlock possible
On Thu, 8 Apr 2021 08:18:21 +0200
Greg KH wrote:
> And I would love a taint for rmmod, but what is that going to help out
> with?
Just like any other taint. If a rmmod can cause the system to lose
integrity, the rmmod could cause a subtle issue that manifests itself into
something more serious
On Thu, Apr 08, 2021 at 10:35:17AM +0200, Jiri Kosina wrote:
> On Thu, 8 Apr 2021, Greg KH wrote:
>
> > > If there is a driver/subsystem code that can't handle the reverse
> > > operation to modprobe, it clearly can't handle error handling during
> > > modprobe (which, one would hope, is
On Thu, 8 Apr 2021, Greg KH wrote:
> > If there is a driver/subsystem code that can't handle the reverse
> > operation to modprobe, it clearly can't handle error handling during
> > modprobe (which, one would hope, is supported), and should be fixed.
>
> Huh? No, that's not the issue here,
On Thu, Apr 08, 2021 at 10:01:23AM +0200, Jiri Kosina wrote:
> On Thu, 8 Apr 2021, Greg KH wrote:
>
> > Removing a module from a system has always been "let's try it and see!"
> > type of operation for a very long time.
>
> Which part of it?
>
> If there is a driver/subsystem code that can't
On Thu, 8 Apr 2021, Greg KH wrote:
> Removing a module from a system has always been "let's try it and see!"
> type of operation for a very long time.
Which part of it?
If there is a driver/subsystem code that can't handle the reverse
operation to modprobe, it clearly can't handle error
On Wed, Apr 07, 2021 at 03:17:46PM -0500, Josh Poimboeuf wrote:
> On Fri, Apr 02, 2021 at 09:54:12AM +0200, Greg KH wrote:
> > On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> > > As for the syfs deadlock possible with drivers, this fixes it in a
> > > generic way:
> > >
> > >
On Thu, Apr 08, 2021 at 03:37:53AM +0200, Thomas Gleixner wrote:
> Greg,
>
> On Fri, Apr 02 2021 at 09:54, Greg KH wrote:
> > On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> >> As for the syfs deadlock possible with drivers, this fixes it in a generic
> >> way:
> >>
> >>
Greg,
On Fri, Apr 02 2021 at 09:54, Greg KH wrote:
> On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
>> As for the syfs deadlock possible with drivers, this fixes it in a generic
>> way:
>>
>> commit fac43d8025727a74f80a183cc5eb74ed902a5d14
>> Author: Luis Chamberlain
>>
On Fri, Apr 02, 2021 at 09:54:12AM +0200, Greg KH wrote:
> On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> > As for the syfs deadlock possible with drivers, this fixes it in a generic
> > way:
> >
> > commit fac43d8025727a74f80a183cc5eb74ed902a5d14
> > Author: Luis
On Wed, Apr 07, 2021 at 10:30:31AM -0500, Josh Poimboeuf wrote:
> On Wed, Apr 07, 2021 at 04:09:44PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 06, 2021 at 10:54:23AM -0500, Josh Poimboeuf wrote:
> >
> > > Same for Red Hat. Unloading livepatch modules seems to work fine, but
> > > isn't
On Wed, Apr 07, 2021 at 04:09:44PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 06, 2021 at 10:54:23AM -0500, Josh Poimboeuf wrote:
>
> > Same for Red Hat. Unloading livepatch modules seems to work fine, but
> > isn't officially supported.
> >
> > That said, if rmmod is just considered a
On Tue, Apr 06, 2021 at 06:38:24PM -0700, Minchan Kim wrote:
> To clarify what I understood form the discussion until now:
>
> 1. zram shouldn't allow creating more zram instance during
> rmmod(It causes CPU multistate splat)
Right!
> 2. the private data of gendisk shouldn't destroyed while
On Tue, Apr 06, 2021 at 06:23:46PM -0700, Minchan Kim wrote:
> On Tue, Apr 06, 2021 at 12:29:09AM +, Luis Chamberlain wrote:
> > On Mon, Apr 05, 2021 at 12:58:05PM -0700, Minchan Kim wrote:
> > > On Mon, Apr 05, 2021 at 07:00:23PM +, Luis Chamberlain wrote:
> > > > Which is why the
On Tue, Apr 06, 2021 at 10:54:23AM -0500, Josh Poimboeuf wrote:
> Same for Red Hat. Unloading livepatch modules seems to work fine, but
> isn't officially supported.
>
> That said, if rmmod is just considered a development aid, and we're
> going to be ignoring bugs, we should make it official
On Tue, Apr 06, 2021 at 06:23:46PM -0700, Minchan Kim wrote:
> On Tue, Apr 06, 2021 at 12:29:09AM +, Luis Chamberlain wrote:
> > On Mon, Apr 05, 2021 at 12:58:05PM -0700, Minchan Kim wrote:
> > > On Mon, Apr 05, 2021 at 07:00:23PM +, Luis Chamberlain wrote:
> > > > On Mon, Apr 05, 2021 at
On Tue, Apr 06, 2021 at 12:29:09AM +, Luis Chamberlain wrote:
> On Mon, Apr 05, 2021 at 12:58:05PM -0700, Minchan Kim wrote:
> > On Mon, Apr 05, 2021 at 07:00:23PM +, Luis Chamberlain wrote:
> > > On Mon, Apr 05, 2021 at 10:07:24AM -0700, Minchan Kim wrote:
> > > > On Thu, Apr 01, 2021 at
On Tue, Apr 06, 2021 at 02:00:19PM +0200, Miroslav Benes wrote:
> Hi,
>
> > > Driver developers will simply have to open code these protections. In
> > > light of what I see on LTP / fuzzing, I suspect the use case will grow
> > > and we'll have to revisit this in the future. But for now, sure,
Hi,
> > Driver developers will simply have to open code these protections. In
> > light of what I see on LTP / fuzzing, I suspect the use case will grow
> > and we'll have to revisit this in the future. But for now, sure, we can
> > just open code the required protections everywhere to not crash
On Mon, Apr 05, 2021 at 12:58:05PM -0700, Minchan Kim wrote:
> On Mon, Apr 05, 2021 at 07:00:23PM +, Luis Chamberlain wrote:
> > On Mon, Apr 05, 2021 at 10:07:24AM -0700, Minchan Kim wrote:
> > > On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> > > > And come to think of it
On Mon, Apr 05, 2021 at 07:00:23PM +, Luis Chamberlain wrote:
> On Mon, Apr 05, 2021 at 10:07:24AM -0700, Minchan Kim wrote:
> > On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> > > And come to think of it the last patch I had sent with a new
> > > DECLARE_RWSEM(zram_unload)
On Mon, Apr 05, 2021 at 10:07:24AM -0700, Minchan Kim wrote:
> On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> > And come to think of it the last patch I had sent with a new
> > DECLARE_RWSEM(zram_unload) also has this same issue making most
> > sysfs attributes rather fragile.
On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> On Mon, Mar 22, 2021 at 03:12:01PM -0700, Minchan Kim wrote:
> > On Mon, Mar 22, 2021 at 08:41:56PM +, Luis Chamberlain wrote:
> > >
> > > I would not call it *every* syfs knob as not all deal with things which
> > > are
On Fri, Apr 02, 2021 at 06:30:16PM +, Luis Chamberlain wrote:
> On Fri, Apr 02, 2021 at 09:54:12AM +0200, Greg KH wrote:
> > On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> > > As for the syfs deadlock possible with drivers, this fixes it in a
> > > generic way:
> > >
> >
On Fri, Apr 02, 2021 at 09:54:12AM +0200, Greg KH wrote:
> On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> > As for the syfs deadlock possible with drivers, this fixes it in a generic
> > way:
> >
> > commit fac43d8025727a74f80a183cc5eb74ed902a5d14
> > Author: Luis
On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> As for the syfs deadlock possible with drivers, this fixes it in a generic
> way:
>
> commit fac43d8025727a74f80a183cc5eb74ed902a5d14
> Author: Luis Chamberlain
> Date: Sat Mar 27 14:58:15 2021 +
>
> sysfs: add
On Mon, Mar 22, 2021 at 03:12:01PM -0700, Minchan Kim wrote:
> On Mon, Mar 22, 2021 at 08:41:56PM +, Luis Chamberlain wrote:
> >
> > I would not call it *every* syfs knob as not all deal with things which
> > are related to CPU hotplug multistate, right? Note that using just
> >
On Mon, Mar 22, 2021 at 08:41:56PM +, Luis Chamberlain wrote:
> On Mon, Mar 22, 2021 at 09:37:17AM -0700, Minchan Kim wrote:
> > On Fri, Mar 19, 2021 at 07:09:24PM +, Luis Chamberlain wrote:
> > > Indeed one issue is a consequence of the other but a bit better
> > > description can be put
On Mon, Mar 22, 2021 at 09:37:17AM -0700, Minchan Kim wrote:
> On Fri, Mar 19, 2021 at 07:09:24PM +, Luis Chamberlain wrote:
> > Indeed one issue is a consequence of the other but a bit better
> > description can be put together for both separately.
> >
> > The warning comes up when cpu
On Fri, Mar 19, 2021 at 07:09:24PM +, Luis Chamberlain wrote:
> On Fri, Mar 12, 2021 at 11:28:21AM -0800, Minchan Kim wrote:
> > On Fri, Mar 12, 2021 at 06:32:38PM +, Luis Chamberlain wrote:
> > > On Thu, Mar 11, 2021 at 06:14:40PM -0800, Minchan Kim wrote:
> > > > On Wed, Mar 10, 2021 at
On Fri, Mar 12, 2021 at 11:28:21AM -0800, Minchan Kim wrote:
> On Fri, Mar 12, 2021 at 06:32:38PM +, Luis Chamberlain wrote:
> > On Thu, Mar 11, 2021 at 06:14:40PM -0800, Minchan Kim wrote:
> > > On Wed, Mar 10, 2021 at 09:21:28PM +, Luis Chamberlain wrote:
> > > > On Mon, Mar 08, 2021 at
On Fri, Mar 12, 2021 at 06:32:38PM +, Luis Chamberlain wrote:
> On Thu, Mar 11, 2021 at 06:14:40PM -0800, Minchan Kim wrote:
> > On Wed, Mar 10, 2021 at 09:21:28PM +, Luis Chamberlain wrote:
> > > On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> > > > If I understand
On Thu, Mar 11, 2021 at 06:14:40PM -0800, Minchan Kim wrote:
> On Wed, Mar 10, 2021 at 09:21:28PM +, Luis Chamberlain wrote:
> > On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> > > If I understand correctly, bugs you found were related to module
> > > unloading race while the
On Wed, Mar 10, 2021 at 09:21:28PM +, Luis Chamberlain wrote:
> On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> > If I understand correctly, bugs you found were related to module
> > unloading race while the zram are still working.
>
> No, that is a simplifcation of the issue.
On Wed, Mar 10, 2021 at 01:11:15PM +, Luis Chamberlain wrote:
> On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> > On Sat, Mar 06, 2021 at 02:20:34AM +, Luis Chamberlain wrote:
> > > The zram driver makes use of cpu hotplug multistate support,
> > > whereby it associates a
On Wed, Mar 10, 2021 at 01:11:15PM +, Luis Chamberlain wrote:
> I can try to modify it to include second patch first, as that is
> required. There are two separate bugs here.
I tried this, applying the syfs required changes first and then
applying your idea as a secondary patch ends up like
On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> If I understand correctly, bugs you found were related to module
> unloading race while the zram are still working.
No, that is a simplifcation of the issue. The issue consists of
two separate issues:
a) race against module
On Mon, Mar 08, 2021 at 06:55:30PM -0800, Minchan Kim wrote:
> On Sat, Mar 06, 2021 at 02:20:34AM +, Luis Chamberlain wrote:
> > The zram driver makes use of cpu hotplug multistate support,
> > whereby it associates a zram compression stream per CPU. To
> > support CPU hotplug multistate a
On Sat, Mar 06, 2021 at 02:20:34AM +, Luis Chamberlain wrote:
> The zram driver makes use of cpu hotplug multistate support,
> whereby it associates a zram compression stream per CPU. To
> support CPU hotplug multistate a callback enabled to allow
> the driver to do what it needs when a CPU
The zram driver makes use of cpu hotplug multistate support,
whereby it associates a zram compression stream per CPU. To
support CPU hotplug multistate a callback enabled to allow
the driver to do what it needs when a CPU hotplugs.
It is however currently possible to end up removing the
zram
42 matches
Mail list logo
