search for: ports_driver_data

...drivers/char/virtio_console.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index fbeb71953526..05dbfdb9f4af 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -75,7 +75,7 @@ struct ports_driver_data { /* All the console devices handled by this driver */ struct list_head consoles; }; -static struct ports_driver_data pdrvdata; +static struct ports_driver_data pdrvdata = { .next_vtermno = 1}; static DEFINE_SPINLOCK(pdrvdata_lock); static DECLARE_COMPLETION(early_console_added); @@ -1394,...

...ah at redhat.com> How can userspace access the port now? By the time we are cleaning up buffers, there should be no possibility of such accesses. The number of bugfixes here is deeply disturbing. I wonder if it's be easier to rewrite it all with a lock per port, and one global to protect ports_driver_data. Cheers, Rusty. > --- > drivers/char/virtio_console.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > index ce71df1..dd0020d 100644 > --- a/drivers/char/virtio_console.c > +++...

...ah at redhat.com> How can userspace access the port now? By the time we are cleaning up buffers, there should be no possibility of such accesses. The number of bugfixes here is deeply disturbing. I wonder if it's be easier to rewrite it all with a lock per port, and one global to protect ports_driver_data. Cheers, Rusty. > --- > drivers/char/virtio_console.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > index ce71df1..dd0020d 100644 > --- a/drivers/char/virtio_console.c > +++...

...; --- drivers/char/virtio_console.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 13ad9b1..f73ad64 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -78,8 +78,8 @@ struct ports_driver_data { }; static struct ports_driver_data pdrvdata; -DEFINE_SPINLOCK(pdrvdata_lock); -DECLARE_COMPLETION(early_console_added); +static DEFINE_SPINLOCK(pdrvdata_lock); +static DECLARE_COMPLETION(early_console_added); /* This struct holds information that's relevant only for console ports */ s...

...; --- drivers/char/virtio_console.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 13ad9b1..f73ad64 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -78,8 +78,8 @@ struct ports_driver_data { }; static struct ports_driver_data pdrvdata; -DEFINE_SPINLOCK(pdrvdata_lock); -DECLARE_COMPLETION(early_console_added); +static DEFINE_SPINLOCK(pdrvdata_lock); +static DECLARE_COMPLETION(early_console_added); /* This struct holds information that's relevant only for console ports */ s...

...te locking fixes which I noticed while fixing that > bug. > > Port unplug isn't a frequently-used or tested path, so these were > lying unnoticed so far. > >> I wonder if it's be >> easier to rewrite it all with a lock per port, and one global to protect >> ports_driver_data. > > Hm, with this series, I don't see anything that might need extra > locking. Though I'll take a look at this afresh in a while -- and see > if we could simplify something. > > Given that this was necessary only for unplug operations, (and they > aren't a 'r...

...te locking fixes which I noticed while fixing that > bug. > > Port unplug isn't a frequently-used or tested path, so these were > lying unnoticed so far. > >> I wonder if it's be >> easier to rewrite it all with a lock per port, and one global to protect >> ports_driver_data. > > Hm, with this series, I don't see anything that might need extra > locking. Though I'll take a look at this afresh in a while -- and see > if we could simplify something. > > Given that this was necessary only for unplug operations, (and they > aren't a 'r...

...char/virtio_console.c | 16 +++------------- 1 files changed, 3 insertions(+), 13 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index c17b053..031be0b 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -61,9 +61,6 @@ struct ports_driver_data { /* List of all the devices we're handling */ struct list_head portdevs; - /* Number of devices this driver is handling */ - unsigned int index; - /* * This is used to keep track of the number of hvc consoles * spawned by this driver. This number is given as the first @@ -169,9...

...char/virtio_console.c | 16 +++------------- 1 files changed, 3 insertions(+), 13 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index c17b053..031be0b 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -61,9 +61,6 @@ struct ports_driver_data { /* List of all the devices we're handling */ struct list_head portdevs; - /* Number of devices this driver is handling */ - unsigned int index; - /* * This is used to keep track of the number of hvc consoles * spawned by this driver. This number is given as the first @@ -169,9...

.... However, the others are inadequate locking fixes which I noticed while fixing that bug. Port unplug isn't a frequently-used or tested path, so these were lying unnoticed so far. > I wonder if it's be > easier to rewrite it all with a lock per port, and one global to protect > ports_driver_data. Hm, with this series, I don't see anything that might need extra locking. Though I'll take a look at this afresh in a while -- and see if we could simplify something. Given that this was necessary only for unplug operations, (and they aren't a 'regular operation', so we coul...

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now safe to perform

Hey Rusty, These are the patches that rework a few bits to make hot-unplug while ports are open not crash apps (or kernels). The problem is when hot-unplug is performed when a port is open, the cdev struct is kept around by the file pointers and when the app later does a 'close', things go boom-boom. This patch series makes sure port as well as device hot-unplug is now safe to perform

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for