LKML Archive on lore.kernel.org
 help / color / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
						download: 
* Re: [RT v5.11-rt7] WARNING at include/linux/seqlock.h:271 nft_counter_eval
  @ 2021-02-23 14:20 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-02-23 14:20 UTC (permalink / raw)
  To: Juri Lelli
  Cc: Sebastian Andrzej Siewior, linux-rt-users, LKML, Peter Zijlstra

On Tue, Feb 23, 2021 at 02:53:40PM +0100, Juri Lelli wrote:
> On 23/02/21 12:00, Sebastian Andrzej Siewior wrote:
> > On 2021-02-23 11:49:07 [+0100], Juri Lelli wrote:
> > > Hi,
> > Hi,
> >
> > > I'm seeing the following splat right after boot (or during late boot
> > > phases) with v5.11-rt7 (LOCKDEP enabled).
> > …
> > > [   85.273588] WARNING: CPU: 5 PID: 1416 at include/linux/seqlock.h:271 nft_counter_eval+0x95/0x130 [nft_counter]
> > …
> > > [   85.273713] RIP: 0010:nft_counter_eval+0x95/0x130 [nft_counter]
> >
> > This is a per-CPU seqcount_t in net/netfilter/nft_counter.c which is
> > only protected by local_bh_disabled(). The warning expects preemption
> > to be disabled which is the case on !RT but not on RT.
> >
> > Not sure what to do about this. It is doing anything wrong as of now. It
> > is noisy.
>
> So, I'm a bit confused and I'm very likely missing details (still
> digesting the seqprop_ magic), but write_seqcount_being() has
>
>  if (seqprop_preemptible(s))
>      preempt_disable();
>
> which in this case (no lock associated) is defined to return false,

Preemption is disabled if and only if:

  1. It's a CONFIG_PREEMPT_RT=n system
  2. There's a lock associated with the sequence counter
  3. That lock is also preemptible (e.g., a mutex)

In your case, the 3 condititions are OFF. You're on a PREEMPT_RT=y
kernel and the sequence counter in question has no lock associated.

As Sebastian summarized, the error is just "noisy" at this point.

We will of course need to find a (mainline-friendly) way to let the
lockdep splat go away for -rt kernels. But for now, it's not harmful.

Good luck,

--
Ahmed S. Darwish

^ permalink raw reply	[relevance 99%]

* Re: [ANNOUNCE] v5.11-rc4-rt1
  @ 2021-01-22  5:32 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-22  5:32 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Sebastian Andrzej Siewior, Thomas Gleixner, LKML, linux-rt-users,
	Steven Rostedt

On Thu, Jan 21, 2021 at 09:50:08PM +0100, Pavel Machek wrote:
> Hi!
>
> > I'm pleased to announce the v5.11-rc4-rt1 patch set.
> >
> > Changes since v5.10.8-rt24:
> >
> >   - Updated to v5.11-rc4
> >
> > Known issues
> >      - kdb/kgdb can easily deadlock.
> >      - kmsg dumpers expecting not to be called in parallel can clobber
> >        their temp buffer.
> >      - netconsole triggers WARN.
>
> I noticed... lot of code using in_interrupt() to decide what to do is
> making it to 5.10-stable at the moment (and I guess that means
> vanilla, too).
>
> I have recollection that that is not okay thing to do. Am I right?
>

Correct. These macros should not be added to new, non-core, kernel code.

There's an on-going effort to clear them already, as in:

  - https://lkml.kernel.org/r/20201019100629.419020859@linutronix.de		(merged)
  - https://lkml.kernel.org/r/20201126132952.2287996-1-bigeasy@linutronix.de	(merged)
  - https://lkml.kernel.org/r/20210118100955.1761652-1-a.darwish@linutronix.de	(to be merged)

> Examples: 8abec36d1274bbd5ae8f36f3658b9abb3db56c31,
> d68b29584c25dbacd01ed44a3e45abb35353f1de.
>

That's sad.

Maybe it would be wise to let a bot scan lore regularly, and send an
automatic notification to authors whenever their patches reintroduce
these macros to non-core kernel code.

Thanks,

--
Ahmed S. Darwish

^ permalink raw reply	[relevance 99%]

* Re: [RFC PATCH 0/1] net: arcnet: Fix RESET sequence
  2021-01-11 13:54 99% ` Ahmed S. Darwish
@ 2021-01-18 10:45 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-18 10:45 UTC (permalink / raw)
  To: Michael Grzeschik, David S. Miller, Jakub Kicinski, netdev
  Cc: LKML, Thomas Gleixner, Sebastian A. Siewior

On Mon, Jan 11, 2021 at 02:54:06PM +0100, Ahmed S. Darwish wrote:
> Hi,
>
> On Tue, Dec 22, 2020 at 10:03:37AM +0100, Ahmed S. Darwish wrote:
> ...
> >
> > Included is an RFC patch to fix the points above: if the RESET flag is
> > encountered, a workqueue is scheduled to run the generic reset sequence.
> >
> ...
>
> Kind reminder.

Ping. Will anyone look at this?

Thanks,

--
Ahmed S. Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 00/19] scsi: libsas: Remove in_interrupt() check
  @ 2021-01-15 16:41 99%               ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-15 16:41 UTC (permalink / raw)
  To: John Garry
  Cc: James E.J. Bottomley, Martin K. Petersen, Jason Yan,
	Daniel Wagner, Artur Paszkiewicz, Jack Wang, linux-scsi, LKML,
	Thomas Gleixner, Sebastian A. Siewior

On Fri, Jan 15, 2021 at 04:29:51PM +0000, John Garry wrote:
> On 15/01/2021 16:27, Ahmed S. Darwish wrote:
> > Thanks!
> >
> > Shall I add you r-b tag to the whole series then, or only to the ones
> > which directly touch libsas (#3, #12, #16, and #19)?
>
> The whole series, if you like. But there was a nit about fitting some code
> on a single line still, and I think Christoph also had some issue on that
> related topic.
>

Nice. Then I'll send a v3 to fixing these 80 col issues -- including in
the intermediate patches.

> >
> > > As an aside, your analysis showed some quite poor usage of spinlocks in some
> > > drivers, specifically grabbing a lock and then calling into a depth of 3 or
> > > 4 functions.
> > >
> > Correct.
>
> BTW, testing report looked all good.
>

Oh, that's good to hear :)

Have a nice weekend,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 00/19] scsi: libsas: Remove in_interrupt() check
  @ 2021-01-15 16:27 99%           ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2021-01-15 16:27 UTC (permalink / raw)
  To: John Garry
  Cc: James E.J. Bottomley, Martin K. Petersen, Jason Yan,
	Daniel Wagner, Artur Paszkiewicz, Jack Wang, linux-scsi, LKML,
	Thomas Gleixner, Sebastian A. Siewior

On Thu, Jan 14, 2021 at 09:51:35AM +0000, John Garry wrote:
...
>
> To me, the series looks fine. Well, the end result - I didn't go through
> patch by patch. So:
>
> Reviewed-by: John Garry <john.garry@huawei.com>
>

Thanks!

Shall I add you r-b tag to the whole series then, or only to the ones
which directly touch libsas (#3, #12, #16, and #19)?

>
> As an aside, your analysis showed some quite poor usage of spinlocks in some
> drivers, specifically grabbing a lock and then calling into a depth of 3 or
> 4 functions.
>

Correct.

Kind regards,

--
Ahmed S. Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 04/19] scsi: mvsas: Pass gfp_t flags to libsas event notifiers
  @ 2021-01-12 17:03 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-12 17:03 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: James E.J. Bottomley, Martin K. Petersen, John Garry, Jason Yan,
	Daniel Wagner, Artur Paszkiewicz, Jack Wang, linux-scsi,
	intel-linux-scu, LKML, Thomas Gleixner, Sebastian A. Siewior

On Tue, Jan 12, 2021 at 03:46:42PM +0000, Christoph Hellwig wrote:
> >  	} else if (mwq->handler & EXP_BRCT_CHG) {
> >  		phy->phy_event &= ~EXP_BRCT_CHG;
> > -		sas_notify_port_event(sas_phy, PORTE_BROADCAST_RCVD);
> > +		sas_notify_port_event_gfp(sas_phy, PORTE_BROADCAST_RCVD, GFP_ATOMIC);
>
> Please don't add pointless lines > 80 chars.  This seems to happen a lot
> more in the series.

I didn't break the lines because they will be modified at the end of the
series anway.

When the _gfp() suffix is removed (patches #13 => #19), the lines get
within the 80 cols range.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 00/19] scsi: libsas: Remove in_interrupt() check
  @ 2021-01-12 13:19 99%   ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2021-01-12 13:19 UTC (permalink / raw)
  To: John Garry
  Cc: James E.J. Bottomley, Martin K. Petersen, Jason Yan,
	Daniel Wagner, Artur Paszkiewicz, Jack Wang, linux-scsi,
	intel-linux-scu, LKML, Thomas Gleixner, Sebastian A. Siewior

On Tue, Jan 12, 2021 at 11:53:50AM +0000, John Garry wrote:
> On 12/01/2021 11:06, Ahmed S. Darwish wrote:
> > Hi,
> >
> > Changelog v2
> > ------------
...
>
> I'll give this a spin today and help review also then.
>
> There's 18 patches here - it would be very convenient if they were on a
> public branch :)
>

Konstantin's "b4" is your friend:

  https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation

It boils down to:

  $ pip install b4
  $ b4 am -v2 20210112110647.627783-1-a.darwish@linutronix.de

Kind regards,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 02/19] scsi: libsas and users: Remove notifier indirection
  @ 2021-01-12 12:09 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-12 12:09 UTC (permalink / raw)
  To: John Garry
  Cc: James E.J. Bottomley, Martin K. Petersen, Jason Yan,
	Daniel Wagner, Artur Paszkiewicz, Jack Wang, linux-scsi,
	intel-linux-scu, LKML, Thomas Gleixner, Sebastian A. Siewior

On Tue, Jan 12, 2021 at 11:36:21AM +0000, John Garry wrote:
> On 12/01/2021 11:06, Ahmed S. Darwish wrote:
> > From: John Garry<john.garry@huawei.com>
> >
> > The LLDDs report events to libsas with .notify_port_event and
> > .notify_phy_event callbacks.
> >
> > These callbacks are fixed and so there is no reason why we cannot call the
> > functions directly, so do that.
> >
> > This neatens the code slightly.
> >
> > [a.darwish@linutronix.de: Remove the now unused "sas_ha" local variables]
> > Signed-off-by: John Garry<john.garry@huawei.com>
>
> Don't forget your signed-off-by :)
>

Oh, yes.

> >
> > diff --git a/Documentation/scsi/libsas.rst b/Documentation/scsi/libsas.rst
> > index f9b77c7879db..a183b1d84713 100644
> > --- a/Documentation/scsi/libsas.rst
> > +++ b/Documentation/scsi/libsas.rst
> > @@ -189,8 +189,8 @@ num_phys
> >   The event interface::
> >   	/* LLDD calls these to notify the class of an event. */
> > -	void (*notify_port_event)(struct sas_phy *, enum port_event);
> > -	void (*notify_phy_event)(struct sas_phy *, enum phy_event);
> > +	void sas_notify_port_event(struct sas_phy *, enum port_event);
> > +	void sas_notify_phy_event(struct sas_phy *, enum phy_event);
> >   When sas_register_ha() returns, those are set and can be
> >   called by the LLDD to notify the SAS layer of such events
>
> Maybe this was missed in the rebase, but I think that this comment can go/be
> changed at some stage.
>

Yeah, I pulled the patch yesterday from:

  https://github.com/hisilicon/kernel-dev/commit/87fcd7e113dc05b7933260e7fa4588dc3730cc2a

Lemme check if there are any other differences.

Thanks,
--
Ahmed S. Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] MAINTAINERS: Remove intel-linux-scu@intel.com for INTEL C600 SAS DRIVER
  @ 2021-01-12 11:37 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-12 11:37 UTC (permalink / raw)
  To: John Garry
  Cc: jejb, martin.petersen, linux-scsi, linux-kernel, Artur Paszkiewicz

On Tue, Jan 12, 2021 at 07:11:30PM +0800, John Garry wrote:
> The mail address intel-linux-scu@intel.com bounces for Ahmed and I, so
> just remove it.
>
> Cc: Ahmed S. Darwish <a.darwish@linutronix.de>
> Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> Signed-off-by: John Garry <john.garry@huawei.com>
>

Acked-by: Ahmed S. Darwish <a.darwish@linutronix.de>

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] scsi: libsas and users: Remove notifier indirection
  @ 2021-01-12 11:25 99% ` Ahmed S. Darwish
  2021-01-11 17:41 99% ` Ahmed S. Darwish
  1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-12 11:25 UTC (permalink / raw)
  To: John Garry
  Cc: jejb, martin.petersen, artur.paszkiewicz, jinpu.wang, corbet,
	yanaijie, bigeasy, linux-scsi, linux-kernel, intel-linux-scu,
	linux-doc

Hi John,

On Tue, Jan 12, 2021 at 01:28:32AM +0800, John Garry wrote:
> LLDDs report events to libsas with .notify_port_event and
> .notify_phy_event callbacks.
>
> These callbacks are fixed and so there is no reason why the functions
> cannot be called directly, so do that.
>
> This neatens the code slightly, makes it more obvious, and reduces
> function pointer usage, which is generally a good thing. Downside is that
> there are 2x more symbol exports.
>
> Signed-off-by: John Garry <john.garry@huawei.com>
>

Since this patch necessitates a careful manual rebase of _every_ patch
in my series, I've included it at the top of my v2 submission and
rebased everything on top:

    https://lkml.kernel.org/r/20210112110647.627783-1-a.darwish@linutronix.de

Some left-over 'sas_ha' local variables were removed, and I've mentioned
that in the commit log of course.

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] scsi: libsas and users: Remove notifier indirection
  @ 2021-01-11 17:52 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-11 17:52 UTC (permalink / raw)
  To: John Garry
  Cc: jejb, martin.petersen, artur.paszkiewicz, jinpu.wang, corbet,
	yanaijie, linux-scsi, linux-kernel, intel-linux-scu, linux-doc

On Mon, Jan 11, 2021 at 05:44:17PM +0000, John Garry wrote:
> On 11/01/2021 17:41, Ahmed S. Darwish wrote:
> > On Tue, Jan 12, 2021 at 01:28:32AM +0800, John Garry wrote:
> > ...
> > > index a920eced92ec..6a51abdc59ae 100644
> > > --- a/drivers/scsi/mvsas/mv_sas.c
> > > +++ b/drivers/scsi/mvsas/mv_sas.c
> > > @@ -230,7 +230,7 @@ static void mvs_bytes_dmaed(struct mvs_info *mvi, int i)
> > >   	}
> > >
> > >   	sas_ha = mvi->sas;
> > > -	sas_ha->notify_phy_event(sas_phy, PHYE_OOB_DONE);
> > > +	sas_notify_phy_event(sas_phy, PHYE_OOB_DONE);
> > >
> >
> > Minor point: "sas_ha" is now not used anywhere; it should be removed.
> > .
> >
>
> ah, yes, it can be removed.
>

Similarly for drivers/scsi/pm8001/pm8001_sas.c.

(Just discovering these while integrating your patch at the top of my
 series).

> BTW, on separate topic, did intel-linux-scu@intel.com bounce for you?
>

Yup :)

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] scsi: libsas and users: Remove notifier indirection
    2021-01-12 11:25 99% ` Ahmed S. Darwish
@ 2021-01-11 17:41 99% ` Ahmed S. Darwish
    1 sibling, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2021-01-11 17:41 UTC (permalink / raw)
  To: John Garry
  Cc: jejb, martin.petersen, artur.paszkiewicz, jinpu.wang, corbet,
	yanaijie, linux-scsi, linux-kernel, intel-linux-scu, linux-doc

On Tue, Jan 12, 2021 at 01:28:32AM +0800, John Garry wrote:
...
> index a920eced92ec..6a51abdc59ae 100644
> --- a/drivers/scsi/mvsas/mv_sas.c
> +++ b/drivers/scsi/mvsas/mv_sas.c
> @@ -230,7 +230,7 @@ static void mvs_bytes_dmaed(struct mvs_info *mvi, int i)
>  	}
>
>  	sas_ha = mvi->sas;
> -	sas_ha->notify_phy_event(sas_phy, PHYE_OOB_DONE);
> +	sas_notify_phy_event(sas_phy, PHYE_OOB_DONE);
>

Minor point: "sas_ha" is now not used anywhere; it should be removed.

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 00/11] scsi: libsas: Remove in_interrupt() check
  @ 2021-01-11 14:28 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2021-01-11 14:28 UTC (permalink / raw)
  To: John Garry
  Cc: Jason Yan, Hannes Reinecke, James E.J. Bottomley,
	Martin K. Petersen, Daniel Wagner, Artur Paszkiewicz, Jack Wang,
	linux-scsi, LKML, Thomas Gleixner, Sebastian A. Siewior

On Mon, Jan 11, 2021 at 01:59:25PM +0000, John Garry wrote:
...
> To me, what you're doing seems fine.
>
...
>
> Just one other thing to mention:
> I have a patch to remove the indirection in libsas notifiers:
> https://github.com/hisilicon/kernel-dev/commit/87fcd7e113dc05b7933260e7fa4588dc3730cc2a
>
> I was going to send it today. Hopefully, if community has no problem with
> it, you can make your changes with that in mind.
>

Perfect. I'll rebase on top of it if everything is OK there.

I'll also append some patches to the series, removing the _gfp() suffix,
per your request earlier:

  https://lkml.kernel.org/r/68957d37-c789-0f0e-f5d1-85fef7f39f4f@huawei.com

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [RFC PATCH 0/1] net: arcnet: Fix RESET sequence
  @ 2021-01-11 13:54 99% ` Ahmed S. Darwish
  2021-01-18 10:45 99%   ` Ahmed S. Darwish
  0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2021-01-11 13:54 UTC (permalink / raw)
  To: Michael Grzeschik, David S. Miller, Jakub Kicinski, netdev
  Cc: LKML, Thomas Gleixner, Sebastian A. Siewior

Hi,

On Tue, Dec 22, 2020 at 10:03:37AM +0100, Ahmed S. Darwish wrote:
...
>
> Included is an RFC patch to fix the points above: if the RESET flag is
> encountered, a workqueue is scheduled to run the generic reset sequence.
>
...

Kind reminder.

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 00/11] scsi: libsas: Remove in_interrupt() check
  @ 2021-01-11 13:43 99% ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2021-01-11 13:43 UTC (permalink / raw)
  To: John Garry, Jason Yan
  Cc: Hannes Reinecke, James E.J. Bottomley, Martin K. Petersen,
	Daniel Wagner, Artur Paszkiewicz, Jack Wang, linux-scsi, LKML,
	Thomas Gleixner, Sebastian A. Siewior

Hi John, Jason,

On Tue, Dec 22, 2020 at 12:54:58PM +0000, John Garry wrote:
> On 22/12/2020 12:30, Jason Yan wrote:
> > >      return event;
> > >
> > >
> > > So default for phy->ha->event_thres is 32, and I can't imagine that
> >
> > The default value is 1024.
>
> Ah, 32 is the minimum allowed set via sysfs.
>
> >
> > > anyone has ever reconfigured this via sysfs or even required a value
> > > that large. Maybe Jason (cc'ed) knows better. It's an arbitrary
> > > value to say that the PHY is malfunctioning. I do note that there is
> > > the circular path sas_alloc_event() -> sas_notify_phy_event() ->
> > > sas_alloc_event() there also.
> > >
> > > Anyway, if the 32x event memories were per-allocated, maybe there is
> > > a clean method to manage this memory, which even works in atomic
> > > context, so we could avoid this rework (ignoring the context bugs
> > > you reported for a moment). I do also note that the sas_event_cache
> > > size is not huge.
> > >
> >
> > Pre-allocated memory is an option.(Which we have tried at the very
> > beginnig by Wang Yijing.)
>
> Right, I remember this, but I think the concern was having a proper method
> to manage this pre-allocated memory then. And same problem now.
>
> >
> > Or directly use GFP_ATOMIC is maybe better than passing flags from lldds.
> >
>
> I think that if we don't really need this, then should not use it.
>

Kind reminder. Do we have any consensus here?

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [RFC PATCH 1/3] chelsio: cxgb: Remove ndo_poll_controller()
  @ 2020-12-24 13:31 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-12-24 13:31 UTC (permalink / raw)
  To: Rahul Lakkireddy, Rohit Maheshwari, Vinay Kumar Yadav,
	Vishal Kulkarni, netdev
  Cc: David S. Miller, Jakub Kicinski, Eric Dumazet, LKML,
	Thomas Gleixner, Sebastian A. Siewior

[[ Actually adding Eric to Cc ]]

On Thu, Dec 24, 2020 at 02:11:46PM +0100, Ahmed S. Darwish wrote:
> Since commit ac3d9dd034e5 ("netpoll: make ndo_poll_controller()
> optional"), networking drivers which use NAPI for clearing their TX
> completions should not provide an ndo_poll_controller(). Netpoll simply
> triggers the necessary TX queues cleanup by synchronously calling the
> driver's NAPI poll handler -- with irqs off and a zero budget.
>
> Modify the cxgb's poll method to clear the TX queues upon zero budget.
> Per API requirements, make sure to never consume any RX packet in that
> case (budget=0), and thus also not to increment the budget upon return.
>
> Afterwards, remove ndo_poll_controller().
>
> Link: https://lkml.kernel.org/r/20180921222752.101307-1-edumazet@google.com
> Link: https://lkml.kernel.org/r/A782704A-DF97-4E85-B10A-D2268A67DFD7@fb.com
> References: 822d54b9c2c1 ("netpoll: Drop budget parameter from NAPI polling call hierarchy")
> Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
> Cc: Eric Dumazet <edumazet@google.com>
> ---
>  drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 14 --------------
>  drivers/net/ethernet/chelsio/cxgb/sge.c   |  9 ++++++++-
>  2 files changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
> index 0e4a0f413960..7b5a98330ef7 100644
> --- a/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
> +++ b/drivers/net/ethernet/chelsio/cxgb/cxgb2.c
> @@ -878,17 +878,6 @@ static int t1_set_features(struct net_device *dev, netdev_features_t features)
>
>  	return 0;
>  }
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> -static void t1_netpoll(struct net_device *dev)
> -{
> -	unsigned long flags;
> -	struct adapter *adapter = dev->ml_priv;
> -
> -	local_irq_save(flags);
> -	t1_interrupt(adapter->pdev->irq, adapter);
> -	local_irq_restore(flags);
> -}
> -#endif
>
>  /*
>   * Periodic accumulation of MAC statistics.  This is used only if the MAC
> @@ -973,9 +962,6 @@ static const struct net_device_ops cxgb_netdev_ops = {
>  	.ndo_set_mac_address	= t1_set_mac_addr,
>  	.ndo_fix_features	= t1_fix_features,
>  	.ndo_set_features	= t1_set_features,
> -#ifdef CONFIG_NET_POLL_CONTROLLER
> -	.ndo_poll_controller	= t1_netpoll,
> -#endif
>  };
>
>  static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> diff --git a/drivers/net/ethernet/chelsio/cxgb/sge.c b/drivers/net/ethernet/chelsio/cxgb/sge.c
> index 2d9c2b5a690a..d6df1a87db0b 100644
> --- a/drivers/net/ethernet/chelsio/cxgb/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb/sge.c
> @@ -1609,7 +1609,14 @@ static int process_pure_responses(struct adapter *adapter)
>  int t1_poll(struct napi_struct *napi, int budget)
>  {
>  	struct adapter *adapter = container_of(napi, struct adapter, napi);
> -	int work_done = process_responses(adapter, budget);
> +	int work_done = 0;
> +
> +	if (budget)
> +		work_done = process_responses(adapter, budget);
> +	else {
> +		/* budget=0 means: don't poll rx data */
> +		process_pure_responses(adapter);
> +	}
>
>  	if (likely(work_done < budget)) {
>  		napi_complete_done(napi, work_done);
> --
> 2.29.2
>

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 11/11] scsi: libsas: event notifiers: Remove non _gfp() variants
  @ 2020-12-21 17:38 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-12-21 17:38 UTC (permalink / raw)
  To: John Garry
  Cc: James E.J. Bottomley, Martin K. Petersen, Daniel Wagner,
	Jason Yan, Artur Paszkiewicz, Jack Wang, linux-scsi, LKML,
	Thomas Gleixner, Sebastian A. Siewior

On Mon, Dec 21, 2020 at 05:17:13PM +0000, John Garry wrote:
> On 18/12/2020 20:43, Ahmed S. Darwish wrote:
> > All call-sites of below libsas APIs:
> >
> >    - sas_alloc_event()
> >    - sas_ha_struct::notify_port_event()
> >    - sas_ha_struct::notify_phy_event()
> >
> > have been converted to use the new _gfp()-suffixed version.
> >
>
> nit: Is it possible to have non- _gfp()-suffixed symbols at the end, i.e.
> have same as original?
>

Yes, of course. I just did not want to double-fold the patch series size
from first submission ;-)

If the overall outlook of this series is OK, in v2 I'll append patches
#12 => #20 restoring call sites to the original names without _gfp(),
then keep only the original libsas names.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] scsi/NCR5380: Remove in_interrupt() test
  @ 2020-12-04 16:08 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-12-04 16:08 UTC (permalink / raw)
  To: Finn Thain
  Cc: Sebastian Andrzej Siewior, Michael Schmitz, James E.J. Bottomley,
	Martin K. Petersen, Thomas Gleixner, linux-scsi, linux-kernel

On Fri, Dec 04, 2020 at 10:08:08AM +1100, Finn Thain wrote:
...
>
> You've put your finger on a known problem with certain
> NCR5380_poll_politely() call sites. That is, the nominal timeout, HZ / 64,
> is meaningless because it is ignored in atomic context. So you may as well
> specify 0 jiffies at these call sites. (There will be a 1 jiffy timeout
> applied regardless.)
...
>
> However, I can see the value in your approach, i.e. passing a zero timeout
> to NCR5380_poll_politely() whenever that argument is unused. And I agree
> that this could then be used to inhibit sleeping, rather than testing
> irqs_disabled().
>
> So if you really don't like irqs_disabled(), perhaps you can just keep the
> better parts of your two attempts, i.e. passing 0 to
> NCR5380_poll_politely() where appropriate and facilitating that by adding
> a new can_sleep parameter to do_abort() and NCR5380_transfer_pio(), as in,
...
>
> Does that sound like a reasonable compromise?
>

Yes, of course. Thanks a lot.

I've sent a v2.

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 2/2] mm: prevent gup_fast from racing with COW during fork
       [not found]     ` <2-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com>
@ 2020-11-12  7:41 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-11-12  7:41 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-kernel, Peter Xu, Linus Torvalds, Andrea Arcangeli,
	Andrew Morton, Aneesh Kumar K.V, Christoph Hellwig, Hugh Dickins,
	Jan Kara, Jann Horn, John Hubbard, Kirill Shutemov, Kirill Tkhai,
	Leon Romanovsky, Linux-MM, Michal Hocko, Oleg Nesterov

On Tue, Nov 10, 2020 at 07:44:09PM -0400, Jason Gunthorpe wrote:
...
>
> Fixes: f3c64eda3e50 ("mm: avoid early COW write protect games during fork()")
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Link: https://lore.kernel.org/r/CAHk-=wi=iCnYCARbPGjkVJu9eyYeZ13N64tZYLdOB8CP5Q_PLw@mail.gmail.com
> Reviewed-by: John Hubbard <jhubbard@nvidia.com>
> Reviewed-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---

Thanks for the v3 and v4 updates.

For the seqcount_t parts:

  Acked-by: "Ahmed S. Darwish" <a.darwish@linutronix.de>

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3 0/2] Add a seqcount between gup_fast and copy_page_range()
       [not found]     <0-v3-7358966cab09+14e9-gup_fork_jgg@nvidia.com>
@ 2020-11-06 18:52 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-11-06 18:52 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-kernel, Peter Xu, Linus Torvalds, Andrea Arcangeli,
	Andrew Morton, Aneesh Kumar K.V, Christoph Hellwig, Hugh Dickins,
	Jan Kara, Jann Horn, John Hubbard, Kirill Shutemov, Kirill Tkhai,
	Leon Romanovsky, Linux-MM, Michal Hocko, Oleg Nesterov,
	Konstantin Ryabitsev, Sebastian A. Siewior, Thomas Gleixner

On Fri, Nov 06, 2020 at 11:55:12AM -0400, Jason Gunthorpe wrote:
...
>
>  arch/x86/kernel/tboot.c    |   1 +
>  drivers/firmware/efi/efi.c |   1 +
>  include/linux/mm_types.h   |   8 +++
>  kernel/fork.c              |   1 +
>  mm/gup.c                   | 118 +++++++++++++++++++++++--------------
>  mm/init-mm.c               |   1 +
>  mm/memory.c                |  13 +++-
>  7 files changed, 97 insertions(+), 46 deletions(-)
>

Nitpick: Please also use the "--base" option of git format-patch. This
will produce a nice "base-commit: " tag behind the diffstat.

Konstantin's amazing "b4" tool gets much happier with that ;-)

All the best,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during fork
  @ 2020-11-04 19:54 99%                   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-11-04 19:54 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: John Hubbard, Jason Gunthorpe, Peter Xu,
	Linux Kernel Mailing List, Andrea Arcangeli, Andrew Morton,
	Aneesh Kumar K.V, Christoph Hellwig, Hugh Dickins, Jan Kara,
	Jann Horn, Kirill Shutemov, Kirill Tkhai, Leon Romanovsky,
	Linux-MM, Michal Hocko, Oleg Nesterov, Peter Zijlstra,
	Ingo Molnar, Will Deacon, Thomas Gleixner, Sebastian Siewior

On Wed, Nov 04, 2020 at 10:38:57AM -0800, Linus Torvalds wrote:
...
>
> Looks reasonable to me.
>
> And can you add a few comments to the magic type macros, so that it's
> a lot more obvious what the end result was.
...
>
> I can see it when I really look, but when looking at the actual use,
> it's very non-obvious indeed.
>

ACK, will do.

>                  Linus

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [RFC 2/2] printk: Add more information about the printk caller
  @ 2020-09-24  4:24 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-09-24  4:24 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sergey Senozhatsky, Steven Rostedt, John Ogness, Linus Torvalds,
	Thomas Gleixner, Prarit Bhargava, Mark Salyzyn, Chunyan Zhang,
	Orson Zhai, Changki Kim, Sergey Senozhatsky, linux-kernel

On Wed, Sep 23, 2020 at 03:56:17PM +0200, Petr Mladek wrote:
...
>
> -static inline u32 printk_caller_id(void)
> +static enum printk_caller_ctx get_printk_caller_ctx(void)
> +{
> +	if (in_nmi())
> +		return printk_ctx_nmi;
> +
> +	if (in_irq())
> +		return printk_ctx_hardirq;
> +
> +	if (in_softirq())
> +		return printk_ctx_softirq;
> +
> +	return printk_ctx_task;
> +}
> +

in_softirq() here will be true for both softirq contexts *and*
BH-disabled regions. Did you mean in_serving_softirq() instead?

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 4/5] seqlock: seqcount_LOCKNAME_t: Introduce PREEMPT_RT support
  @ 2020-09-08 12:48 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-09-08 12:48 UTC (permalink / raw)
  To: peterz
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Sebastian A. Siewior,
	Paul E. McKenney, Steven Rostedt, LKML

On Tue, Sep 08, 2020 at 01:45:20PM +0200, peterz@infradead.org wrote:
> On Fri, Sep 04, 2020 at 05:32:30PM +0200, Ahmed S. Darwish wrote:
> > @@ -406,13 +443,20 @@ static inline int read_seqcount_t_retry(const seqcount_t *s, unsigned start)
> >  	return __read_seqcount_t_retry(s, start);
> >  }
> >
> > +/*
> > + * Enforce non-preemptibility for all seqcount_LOCKNAME_t writers. Don't
> > + * do it for PREEMPT_RT, for the reasons outlined at __SEQ_LOCK().
> > + */
> > +#define __seq_enforce_writer_non_preemptibility(s)			\
> > +	(!IS_ENABLED(CONFIG_PREEMPT_RT) && __seqcount_lock_preemptible(s))
> > +
> >  /**
> >   * raw_write_seqcount_begin() - start a seqcount_t write section w/o lockdep
> >   * @s: Pointer to seqcount_t or any of the seqcount_LOCKNAME_t variants
> >   */
> >  #define raw_write_seqcount_begin(s)					\
> >  do {									\
> > -	if (__seqcount_lock_preemptible(s))				\
> > +	if (__seq_enforce_writer_non_preemptibility(s))			\
> >  		preempt_disable();					\
> >  									\
> >  	raw_write_seqcount_t_begin(__seqcount_ptr(s));			\
> > @@ -433,7 +477,7 @@ static inline void raw_write_seqcount_t_begin(seqcount_t *s)
> >  do {									\
> >  	raw_write_seqcount_t_end(__seqcount_ptr(s));			\
> >  									\
> > -	if (__seqcount_lock_preemptible(s))				\
> > +	if (__seq_enforce_writer_non_preemptibility(s))			\
> >  		preempt_enable();					\
> >  } while (0)
> >
> > @@ -456,7 +500,7 @@ static inline void raw_write_seqcount_t_end(seqcount_t *s)
> >  do {									\
> >  	__seqcount_assert_lock_held(s);					\
> >  									\
> > -	if (__seqcount_lock_preemptible(s))				\
> > +	if (__seq_enforce_writer_non_preemptibility(s))			\
> >  		preempt_disable();					\
> >  									\
> >  	write_seqcount_t_begin_nested(__seqcount_ptr(s), subclass);	\
> > @@ -483,7 +527,7 @@ static inline void write_seqcount_t_begin_nested(seqcount_t *s, int subclass)
> >  do {									\
> >  	__seqcount_assert_lock_held(s);					\
> >  									\
> > -	if (__seqcount_lock_preemptible(s))				\
> > +	if (__seq_enforce_writer_non_preemptibility(s))			\
> >  		preempt_disable();					\
> >  									\
> >  	write_seqcount_t_begin(__seqcount_ptr(s));			\
> > @@ -504,7 +548,7 @@ static inline void write_seqcount_t_begin(seqcount_t *s)
> >  do {									\
> >  	write_seqcount_t_end(__seqcount_ptr(s));			\
> >  									\
> > -	if (__seqcount_lock_preemptible(s))				\
> > +	if (__seq_enforce_writer_non_preemptibility(s))			\
> >  		preempt_enable();					\
> >  } while (0)
>
> I've replaced the above with the below, afaict there were no users of
> __seqcount_lock_preemptible() left.
>
> --- a/include/linux/seqlock.h
> +++ b/include/linux/seqlock.h
> @@ -228,7 +228,11 @@ __seqprop_##lockname##_sequence(const se
>  static __always_inline bool						\
>  __seqprop_##lockname##_preemptible(const seqcount_##lockname##_t *s)	\
>  {									\
> -	return preemptible;						\
> +	if (!IS_ENABLED(CONFIG_PREEMPT_RT))				\
> +		return preemptible;					\
> +									\
> +	/* PREEMPT_RT relies on the above LOCK+UNLOCK */		\
> +	return false;							\
>  }									\
>  									\

Sounds good.

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 6/8] x86/tsc: Use seqcount_latch_t
  @ 2020-09-08  6:23 99%             ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-09-08  6:23 UTC (permalink / raw)
  To: peterz
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Sebastian A. Siewior,
	LKML, Borislav Petkov, x86, H. Peter Anvin

On Mon, Sep 07, 2020 at 07:30:47PM +0200, peterz@infradead.org wrote:
...
>
> Don't look at this function in isolation, look at native_sched_clock()
> where it's used as a whole.
>
...
> What happened (afaict) is that the change caused it to use more
> registers and ended up spiling crap on the stack.
>
...
>
> Anyway, I frobbed the patch to use the this_cpu variant, and I've queued
> the lot.

Perfect. Thanks a lot ;-)

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 0/5] seqlock: Introduce PREEMPT_RT support
  @ 2020-09-04  7:30 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-09-04  7:30 UTC (permalink / raw)
  To: peterz
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Sebastian A. Siewior,
	Paul E. McKenney, Steven Rostedt, LKML

On Fri, Sep 04, 2020 at 08:52:45AM +0200, peterz@infradead.org wrote:
>
> FWIW, can you please start a new thread with ever posting? I lost this
> one because it got stuck onto some ancient thread.
>

Yeah, I used an old send-mail script, sorry.

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 4/5] seqlock: seqcount_LOCKTYPE_t: Introduce PREEMPT_RT support
  @ 2020-08-28 14:36 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-28 14:36 UTC (permalink / raw)
  To: peterz
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Sebastian A. Siewior,
	Paul E. McKenney, Steven Rostedt, LKML

On Fri, Aug 28, 2020 at 11:31:32AM +0200, Ahmed S. Darwish wrote:
> On Fri, Aug 28, 2020 at 10:59:38AM +0200, peterz@infradead.org wrote:
> > On Fri, Aug 28, 2020 at 03:07:09AM +0200, Ahmed S. Darwish wrote:
> > > +#define __SEQ_RT	IS_ENABLED(CONFIG_PREEMPT_RT)
> > > +
> > > +SEQCOUNT_LOCKTYPE(raw_spinlock, raw_spinlock_t,  false,    s->lock,        raw_spin, raw_spin_lock(s->lock))
> > > +SEQCOUNT_LOCKTYPE(spinlock,     spinlock_t,      __SEQ_RT, s->lock,        spin,     spin_lock(s->lock))
> > > +SEQCOUNT_LOCKTYPE(rwlock,       rwlock_t,        __SEQ_RT, s->lock,        read,     read_lock(s->lock))
> > > +SEQCOUNT_LOCKTYPE(mutex,        struct mutex,    true,     s->lock,        mutex,    mutex_lock(s->lock))
> > > +SEQCOUNT_LOCKTYPE(ww_mutex,     struct ww_mutex, true,     &s->lock->base, ww_mutex, ww_mutex_lock(s->lock, NULL))
> >
> > Ooh, reading is hard, but ^^^^ you already have that.
> >
>
> Haha, I was just answering the other mail :)
>
> > > +/*
> > > + * Automatically disable preemption for seqcount_LOCKTYPE_t writers, if the
> > > + * associated lock does not implicitly disable preemption.
> > > + *
> > > + * Don't do it for PREEMPT_RT. Check __SEQ_LOCK().
> > > + */
> > > +#define __seq_enforce_preemption_protection(s)				\
> > > +	(!IS_ENABLED(CONFIG_PREEMPT_RT) && __seqcount_lock_preemptible(s))
> >
> > Then what is this doing ?!? I'm confused now.
>
> There were a number of call sites (at DRM mainly) that protected their
> seqcount_t write sections with mutex and ww_mutex. So, they manually
> disabled preemption before entering the seqcount_t write sections.
>
> Unfortunately these write sections were big, and spinlocks were also
> acquired inside them.  This was all very bad for RT...
>
> So the idea was to relieve call sites from the responsibility of
> disabling/enabling preemption upon entering a seqcount_LOCKNAME_t write
> section, and let seqlock.h automatically handle it if LOCKNAME_t is
> preemptible (the macro's condition, second part).
>
> Having seqlock.h control the preempt disable/enable allows us to never
> disable preemption for RT, which is exactly what is needed since we
> already handle any possible livelock through the mechanisms described at
> __SEQ_LOCK (the macro's condition test, first part).
>

So to summarize, __seqcount_lock_preemptible() has two use cases:

    1. For !PREEMPT_RT, to automatically disable preemption on the write
       side when the seqcount associated lock is preemptible.

    2. For PREEMPT_RT, to lock/unlock the seqcount associated lock on
       the read side if it is RT-preemptible (sleeping lock).

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 2/5] seqlock: Use unique prefix for seqcount_t property accessors
  @ 2020-08-28  8:59 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-28  8:59 UTC (permalink / raw)
  To: peterz
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Sebastian A. Siewior,
	Paul E. McKenney, Steven Rostedt, LKML

On Fri, Aug 28, 2020 at 10:27:54AM +0200, peterz@infradead.org wrote:
> On Fri, Aug 28, 2020 at 03:07:07AM +0200, Ahmed S. Darwish wrote:
> > Differentiate the first group by using "__seqcount_t_" as prefix. This
> > also conforms with the rest of seqlock.h naming conventions.
>
> >  #define __seqprop_case(s, locktype, prop)				\
> >  	seqcount_##locktype##_t: __seqcount_##locktype##_##prop((void *)(s))
> >
> >  #define __seqprop(s, prop) _Generic(*(s),				\
> > -	seqcount_t:		__seqcount_##prop((void *)(s)),		\
> > +	seqcount_t:		__seqcount_t_##prop((void *)(s)),	\
> >  	__seqprop_case((s),	raw_spinlock,	prop),			\
> >  	__seqprop_case((s),	spinlock,	prop),			\
> >  	__seqprop_case((s),	rwlock,		prop),			\
>
> If instead you do:
>
> #define __seqprop_case(s, _lockname, prop) \
> 	seqcount##_lockname##_t: __seqcount##_lockname##_##prop((void *)(s))
>
> You can have:
>
> 	__seqprop_case((s),	,		prop),
> 	__seqprop_case((s),	_raw_spinlock,	prop),
> 	__seqprop_case((s),	_spinlock,	prop),
> 	__seqprop_case((s),	_rwlock,	prop),
> 	__seqprop_case((s),	_mutex,		prop),
> 	__seqprop_case((s),	_ww_mutex,	prop),
>
> And it's all good again.
>
> Although arguably we should do something like s/__seqcount/__seqprop/
> over this lot.
>

ACK.

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 3/5] seqlock: seqcount_t: Implement all read APIs as statement expressions
  @ 2020-08-28  8:37 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-28  8:37 UTC (permalink / raw)
  To: peterz
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Sebastian A. Siewior,
	Paul E. McKenney, Steven Rostedt, LKML

On Fri, Aug 28, 2020 at 10:30:22AM +0200, peterz@infradead.org wrote:
> On Fri, Aug 28, 2020 at 03:07:08AM +0200, Ahmed S. Darwish wrote:
> >  #define __read_seqcount_begin(s)					\
> > +({									\
> > +	unsigned seq;							\
> > +									\
> > +	do {								\
> > +		seq = __seqcount_sequence(s);				\
> > +		if (likely(! (seq & 1)))				\
> > +			break;						\
> > +		cpu_relax();						\
> > +	} while (true);							\
> > +									\
> > +	kcsan_atomic_next(KCSAN_SEQLOCK_REGION_MAX);			\
> > +	seq;								\
> > +})
>
> Since we're there anyway, does it make sense to (re)write this like:
>
> 	while ((seq = __seqcount_sequence(s)) & 1)
> 		cpu_relax();
>
> ?
>

Yeah, much better of course; will do.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 1/5] seqlock: seqcount_LOCKTYPE_t: Standardize naming convention
  @ 2020-08-28  8:24 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-28  8:24 UTC (permalink / raw)
  To: peterz
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Sebastian A. Siewior,
	Paul E. McKenney, Steven Rostedt, LKML

Hi :)

On Fri, Aug 28, 2020 at 10:18:44AM +0200, peterz@infradead.org wrote:
> On Fri, Aug 28, 2020 at 03:07:06AM +0200, Ahmed S. Darwish wrote:
> > At seqlock.h, sequence counters with associated locks are either called
> > seqcount_LOCKNAME_t, seqcount_LOCKTYPE_t, or seqcount_locktype_t.
> >
> > Standardize on "seqcount_LOCKTYPE_t" for all instances in comments,
> > kernel-doc, and SEQCOUNT_LOCKTYPE() generative macro paramters.
>
> > +#define SEQCOUNT_LOCKTYPE(locktype, locktype_t, preemptible, lockmember)	\
> > +typedef struct seqcount_##locktype {					\
> > +	__SEQ_LOCK(locktype_t	*lock);					\
> > +} seqcount_##locktype##_t;						\
>
> Hurmph, so my thinking was that the above 'locktype' is not actually a
> type and therefore a misnomer.
>
> But I see your point about it being a bit of a mess.
>
> Would:
>
>  s/LOCKTYPE/LOCKNAME/g
>  s/seqcount_locktype_t/seqcount_LOCKNAME_t/g
>
> help? Then we're consistently at: seqcount_LOCKNAME_t, which is a type.
>

Sounds good, will do.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* [PATCH v1 7/8] rbtree_latch: Use seqcount_latch_t
  @ 2020-08-27 11:40 99%   ` Ahmed S. Darwish
  2020-08-27 11:40 99%   ` [PATCH v1 4/8] time/sched_clock: " Ahmed S. Darwish
    2 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-27 11:40 UTC (permalink / raw)
  To: Peter Zijlstra, Ingo Molnar, Will Deacon
  Cc: Thomas Gleixner, Sebastian A. Siewior, LKML, Ahmed S. Darwish

Latch sequence counters have unique read and write APIs, and thus
seqcount_latch_t was recently introduced at seqlock.h.

Use that new data type instead of plain seqcount_t. This adds the
necessary type-safety and ensures that only latching-safe seqcount APIs
are to be used.

Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
---
 include/linux/rbtree_latch.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/rbtree_latch.h b/include/linux/rbtree_latch.h
index 7d012faa509a..3d1a9e716b80 100644
--- a/include/linux/rbtree_latch.h
+++ b/include/linux/rbtree_latch.h
@@ -42,8 +42,8 @@ struct latch_tree_node {
 };
 
 struct latch_tree_root {
-	seqcount_t	seq;
-	struct rb_root	tree[2];
+	seqcount_latch_t	seq;
+	struct rb_root		tree[2];
 };
 
 /**
@@ -206,7 +206,7 @@ latch_tree_find(void *key, struct latch_tree_root *root,
 	do {
 		seq = raw_read_seqcount_latch(&root->seq);
 		node = __lt_find(key, root, seq & 1, ops->comp);
-	} while (read_seqcount_retry(&root->seq, seq));
+	} while (read_seqcount_latch_retry(&root->seq, seq));
 
 	return node;
 }
-- 
2.28.0


^ permalink raw reply	[relevance 99%]

* [PATCH v1 4/8] time/sched_clock: Use seqcount_latch_t
    2020-08-27 11:40 99%   ` [PATCH v1 7/8] rbtree_latch: Use seqcount_latch_t Ahmed S. Darwish
@ 2020-08-27 11:40 99%   ` Ahmed S. Darwish
    2 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-27 11:40 UTC (permalink / raw)
  To: Peter Zijlstra, Ingo Molnar, Will Deacon
  Cc: Thomas Gleixner, Sebastian A. Siewior, LKML, Ahmed S. Darwish

Latch sequence counters have unique read and write APIs, and thus
seqcount_latch_t was recently introduced at seqlock.h.

Use that new data type instead of plain seqcount_t. This adds the
necessary type-safety and ensures only latching-safe seqcount APIs are
to be used.

Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
---
 kernel/time/sched_clock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 8c6b5febd7a0..0642013dace4 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -35,7 +35,7 @@
  * into a single 64-byte cache line.
  */
 struct clock_data {
-	seqcount_t		seq;
+	seqcount_latch_t	seq;
 	struct clock_read_data	read_data[2];
 	ktime_t			wrap_kt;
 	unsigned long		rate;
@@ -76,7 +76,7 @@ struct clock_read_data *sched_clock_read_begin(unsigned int *seq)
 
 int sched_clock_read_retry(unsigned int seq)
 {
-	return read_seqcount_retry(&cd.seq, seq);
+	return read_seqcount_latch_retry(&cd.seq, seq);
 }
 
 unsigned long long notrace sched_clock(void)
-- 
2.28.0


^ permalink raw reply	[relevance 99%]

* Re: v5.9-rc1 commit reliably breaks pci nvme detection
  @ 2020-08-20 17:07 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-20 17:07 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Keith Busch, linux-nvme, Sagi Grimberg, Chaitanya Kulkarni, linux-kernel

On Thu, Aug 20, 2020 at 09:35:38AM -0600, Jens Axboe wrote:
> On 8/17/20 9:58 AM, Jens Axboe wrote:
> > On 8/17/20 8:56 AM, Keith Busch wrote:
> >> On Mon, Aug 17, 2020 at 03:50:11PM +0200, Ahmed S. Darwish wrote:
> >>> Hello,
> >>>
> >>> Below v5.9-rc1 commit reliably breaks my boot on a Thinkpad e480
> >>> laptop. PCI nvme detection fails, and the kernel becomes not able
> >>> anymore to find the rootfs / parse "root=".
> >>>
> >>> Bisecting v5.8=>v5.9-rc1 blames that commit. Reverting it *reliably*
> >>> fixes the problem and makes me able to boot v5.9-rc1.
> >>
> >> The fix is staged in the nvme tree here:
> >>
> >>   http://git.infradead.org/nvme.git/commit/286155561ecd13b6c85a78eaf2880d3baea03b9e
> >
> > That would have been nice to have in -rc1...
>
> And now we're getting very close to shipping items for -rc2, and it's still
> not in. Can we please get the nvme pull request out for -rc2?
>

I keep wondering that myself. Completely breaking the boot like this is
really not nice -- and for x86-64 laptops no less :-(

The fix is really small and isolated. "Urgent pull requests", containing
only a fix or two, were created *exactly* for this reson...

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Revert "seqlock: lockdep assert non-preemptibility on seqcount_t write"
  @ 2020-08-10 10:35 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-10 10:35 UTC (permalink / raw)
  To: Greg KH
  Cc: bigeasy, linux-kernel, linux, mingo, paulmck, peterz, rostedt,
	tglx, will

On Mon, Aug 10, 2020 at 12:05:02PM +0200, Greg KH wrote:
> On Mon, Aug 10, 2020 at 11:54:28AM +0200, Ahmed S. Darwish wrote:
> > This reverts commit 859247d39fb008ea812e8f0c398a58a20c12899e.
> >
> > Current implementation of lockdep_assert_preemption_disabled() uses
> > per-CPU variables, which was done to untangle the existing
> > seqlock.h<=>sched.h 'current->' task_struct circular dependency.
> >
> > Using per-CPU variables did not fully untangle the dependency for
> > various non-x86 architectures though, resulting in multiple broken
> > builds. For the affected architectures, raw_smp_processor_id() led
> > back to 'current->', thus having the original seqlock.h<=>sched.h
> > dependency in full-effect.
> >
> > For now, revert adding lockdep_assert_preemption_disabled() to
> > seqlock.h.
> >
> > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > Link: https://lkml.kernel.org/r/20200808232122.GA176509@roeck-us.net
> > Link: https://lkml.kernel.org/r/20200810085954.GA1591892@kroah.com
> > References: Commit a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu variables")
> > Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Even after this, there are still some build errors on arm32, but I don't
> think they are due to this change:
>
> 	ERROR: modpost: "__aeabi_uldivmod" [drivers/net/ethernet/sfc/sfc.ko] undefined!
> 	ERROR: modpost: "__bad_udelay" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] undefined!
>

Yes, they are unrelated to the seqlock.h changes.

(I've locally reverted the whole series just to be sure, and the same
 linking errors as above were still there for an ARM allyesconfig.)

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 08/24] seqlock: lockdep assert non-preemptibility on seqcount_t write
  @ 2020-08-09 18:42 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-08-09 18:42 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Thomas Gleixner,
	Paul E. McKenney, Sebastian A. Siewior, Steven Rostedt, LKML

On Sat, Aug 08, 2020 at 04:21:22PM -0700, Guenter Roeck wrote:
> On Mon, Jul 20, 2020 at 05:55:14PM +0200, Ahmed S. Darwish wrote:
> > Preemption must be disabled before entering a sequence count write side
> > critical section.  Failing to do so, the seqcount read side can preempt
> > the write side section and spin for the entire scheduler tick.  If that
> > reader belongs to a real-time scheduling class, it can spin forever and
> > the kernel will livelock.
> >
> > Assert through lockdep that preemption is disabled for seqcount writers.
> >
>
> This patch is causing compile failures for various images (eg arm:allmodconfig,
> arm:imx_v6_v7_defconfig, mips:allmodconfig).
>
> In file included from arch/arm/include/asm/bug.h:60,
>                  from include/linux/bug.h:5,
>                  from include/linux/thread_info.h:12,
>                  from include/asm-generic/current.h:5,
>                  from ./arch/arm/include/generated/asm/current.h:1,
>                  from include/linux/sched.h:12,
>                  from arch/arm/kernel/asm-offsets.c:11:
> include/linux/seqlock.h: In function 'write_seqcount_begin_nested':
> include/asm-generic/percpu.h:31:40: error: implicit declaration of function 'raw_smp_processor_id'
>
> Reverting it fixes the problem. Is this being addressed ?
>

@Peter, I think let's revert this one for now?

Shall I also send you a version of:

    [PATCH v4 09/24] seqlock: Extend seqcount API with associated locks
    https://lkml.kernel.org/r/20200720155530.1173732-10-a.darwish@linutronix.de/

with the problematic "lockdep_assert_preemption_disabled()" removed?

> Guenter
>

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5/5] seqcount: More consistent seqprop names
  @ 2020-07-29 14:39 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-29 14:39 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: mingo, will, tglx, paulmck, bigeasy, rostedt, linux-kernel,
	corbet, davem, netdev, linux-doc, viro, linux-fsdevel

On Wed, Jul 29, 2020 at 03:52:54PM +0200, Peter Zijlstra wrote:
> Attempt uniformity and brevity.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---

Acked-by: Ahmed S. Darwish <a.darwish@linutronix.de>

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 2/5] seqlock: Fold seqcount_LOCKNAME_t definition
  @ 2020-07-29 14:38 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-29 14:38 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: mingo, will, tglx, paulmck, bigeasy, rostedt, linux-kernel,
	corbet, davem, netdev, linux-doc, viro, linux-fsdevel

On Wed, Jul 29, 2020 at 03:52:51PM +0200, Peter Zijlstra wrote:
> Manual repetition is boring and error prone.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---

...

> +/**
> + * typedef seqcount_LOCKNAME_t - sequence counter with spinlock associated

                                                        ^ associated lock

> + * @seqcount:	The real sequence counter
> + * @lock:	Pointer to the associated spinlock
> + *

              ^ Pointer to the associated write serialization lock

> + * A plain sequence counter with external writer synchronization by a
> + * spinlock. The spinlock is associated to the sequence count in the
> + * static initializer or init function. This enables lockdep to validate
> + * that the write side critical section is properly serialized.

ditto, you forgot to change the associated spinlock language to generic
locks ;-)

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 1/5] seqlock: s/__SEQ_LOCKDEP/__SEQ_LOCK/g
  @ 2020-07-29 14:29 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-29 14:29 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: mingo, will, tglx, paulmck, bigeasy, rostedt, linux-kernel,
	corbet, davem, netdev, linux-doc, viro, linux-fsdevel

On Wed, Jul 29, 2020 at 03:52:50PM +0200, Peter Zijlstra wrote:
> __SEQ_LOCKDEP() is an expression gate for the
> seqcount_LOCKNAME_t::lock member. Rename it to be about the member,
> not the gate condition.
>
> Later (PREEMPT_RT) patches will make the member available for !LOCKDEP
> configs.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---

Acked-by: Ahmed S. Darwish <a.darwish@linutronix.de>

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 01/24] Documentation: locking: Describe seqlock design and usage
  @ 2020-07-21  5:34 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-21  5:34 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Thomas Gleixner,
	Paul E. McKenney, Sebastian A. Siewior, LKML, Jonathan Corbet,
	linux-doc

On Mon, Jul 20, 2020 at 09:35:51PM -0400, Steven Rostedt wrote:
> On Mon, 20 Jul 2020 17:55:07 +0200
> "Ahmed S. Darwish" <a.darwish@linutronix.de> wrote:
> > +Read path, three categories:
> > +
> > +1. Normal Sequence readers which never block a writer but they must
> > +   retry if a writer is in progress by detecting change in the sequence
> > +   number.  Writers do not wait for a sequence reader::
> > +
> > +	do {
> > +		seq = read_seqbegin(&foo_seqlock);
> > +
> > +		/* ... [[read-side critical section]] ... */
> > +
> > +	} while (read_seqretry(&foo_seqlock, seq));
> > +
> > +2. Locking readers which will wait if a writer or another locking reader
> > +   is in progress. A locking reader in progress will also block a writer
> > +   from entering its critical section. This read lock is
> > +   exclusive. Unlike rwlock_t, only one locking reader can acquire it::
>
> Nit, but I would mention that this acts similar to a normal spin_lock,
> and even disables preeption (in the non-RT case).

will do.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 00/24] seqlock: Extend seqcount API with associated locks
  @ 2020-07-20 17:33 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-20 17:33 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Thomas Gleixner,
	Paul E. McKenney, Sebastian A. Siewior, Steven Rostedt, LKML,
	Jonathan Corbet, linux-doc, David S. Miller, netdev,
	Alexander Viro, linux-fsdevel

On Mon, Jul 20, 2020 at 09:49:12AM -0700, Eric Biggers wrote:
> On Mon, Jul 20, 2020 at 05:55:06PM +0200, Ahmed S. Darwish wrote:
> > Hi,
> >
> > This is v4 of the seqlock patch series:
> >
> >    [PATCH v1 00/25]
> >    https://lore.kernel.org/lkml/20200519214547.352050-1-a.darwish@linutronix.de
> >
> >    [PATCH v2 00/06] (bugfixes-only, merged)
> >    https://lore.kernel.org/lkml/20200603144949.1122421-1-a.darwish@linutronix.de
> >
> >    [PATCH v2 00/18]
> >    https://lore.kernel.org/lkml/20200608005729.1874024-1-a.darwish@linutronix.de
> >
> >    [PATCH v3 00/20]
> >    https://lore.kernel.org/lkml/20200630054452.3675847-1-a.darwish@linutronix.de
> >
> > It is based over:
> >
> >    git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git :: locking/core
> >
>
> Please include an explanation of the patch series in the cover letter.  It looks
> like you sent it in v1 and then stopped including it.  That doesn't work;
> reviewers shouldn't have to read all previous versions too and try to guess
> which parts are still up-to-date.
>

Noted. Thanks for the heads-up.

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 1/6] sched_clock: Expose struct clock_read_data
  @ 2020-07-15  7:21 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-15  7:21 UTC (permalink / raw)
  To: Leo Yan
  Cc: Peter Zijlstra, Will Deacon, Mark Rutland, Ingo Molnar,
	Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
	Namhyung Kim, Catalin Marinas, Thomas Gleixner, Paul Cercueil,
	Ben Dooks (Codethink),
	Adrian Hunter, Kan Liang, jogness, linux-arm-kernel,
	linux-kernel

On Wed, Jul 15, 2020 at 02:54:07PM +0800, Leo Yan wrote:
> On Wed, Jul 15, 2020 at 07:56:50AM +0200, Ahmed S. Darwish wrote:
> > On Wed, Jul 15, 2020 at 10:05:07AM +0800, Leo Yan wrote:
> > > From: Peter Zijlstra <peterz@infradead.org>
> > >
> > ...
> > >
> > > Provide struct clock_read_data and two (seqcount) helpers so that
> > > architectures (arm64 in specific) can expose the numbers to userspace.
> > >
> > ...
> > >
> > > +struct clock_read_data *sched_clock_read_begin(unsigned int *seq)
> > > +{
> > > +	*seq = raw_read_seqcount(&cd.seq);
> > > +	return cd.read_data + (*seq & 1);
> > > +}
> > > +
> > ...
> >
> > Hmm, this seqcount_t is actually a latch seqcount. I know the original
> > code also used raw_read_seqcount(), but while at it, let's use the
> > proper read API for seqcount_t latchers: raw_read_seqcount_latch().
>
> Good point.  To be honest, I think myself cannot give a good judgement
> for memory barrier related thing :)
>
> I read a bit the document for the latch technique [1], comparing to
> raw_read_seqcount_latch(), the function raw_read_seqcount() contains
> smp_rmb(), IIUC, the *read* memory barrier is used to support for
> kcsan.
>

The smp_rmb() has no relation whatsoever to KCSAN. It pairs with the
write memory barriers in the seqcount_t write path.

AFAIK, PeterZ is the author of this patch, so let's wait for his input
here.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3 06/20] seqlock: Extend seqcount API with associated locks
  @ 2020-07-08 15:58 99%                   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-08 15:58 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Paul E. McKenney,
	Sebastian A. Siewior, Steven Rostedt, LKML

On Wed, Jul 08, 2020 at 05:35:22PM +0200, Peter Zijlstra wrote:
...
>
> And while the gcc-4.8 code is horrendous crap, the rest should be pretty
> straight forward and concentrates on the pieces where there are
> differences.
>

Is there any possibility of upgrading the minimum gcc version to 4.9? Is
there any supported architecture that is still stuck on 4.8?

...
> I even considered:
>
> #define __SEQPROP(name, prop, expr) \
> static __always_inline __seqprop_##prop##_t \
> __seqprop##name##_##prop(seqcount##name##_t *s) \
> { \
> 	expr; \
> }
>
> Such that we could write:
>
> __SEQPROP(, ptr, return s)
> __SEQPROP(, preempt, return false)
> __SEQPROP(, assert, )
>
> __SEQPROP(_##locktype, ptr, return &s->seqcount) \
> __SEQPROP(_##locktype, preempt, return preempt) \
> __SEQPROP(_##locktype, assert, __SEQCOUNT_LOCKDEP(lockdep_assert_held(s->lockmember))) \
>
> But I figured _that_ might've been one step too far ;-)

Initially I implemented something like this during internal,
pre-upstream, versions of this patch series. We've decided afterwards
that the macro compression level is so high that the whole thing is not
so easily understandable.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3 06/20] seqlock: Extend seqcount API with associated locks
  @ 2020-07-08 15:09 99%               ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2020-07-08 15:09 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Paul E. McKenney,
	Sebastian A. Siewior, Steven Rostedt, LKML

On Wed, Jul 08, 2020 at 02:29:38PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 08, 2020 at 12:33:14PM +0200, Ahmed S. Darwish wrote:
>
> > > +#define read_seqcount_begin(s)	do_read_seqcount_begin(__to_seqcount_t(s))
> > > +
> > > +static inline unsigned do_read_seqcount_begin(const seqcount_t *s)
> > > +{
> > ...
> >
> > Hmm, the __to_seqcount_t(s) force cast is not good. It will break the
> > arguments type-safety of seqcount macros that do not have either:
> >
> >     __associated_lock_is_preemptible() or
> >     __assert_associated_lock_held()
> >
> > in their path. This basically includes all the read path macros, and
> > even some others (e.g. write_seqcount_invalidate()).
> >
> > With the suggested force cast above, I can literally *pass anything* to
> > read_seqcount_begin() and friends, and the compiler won't say a thing.
> >
> > So, I'll restore __to_seqcount_t(s) that to its original implementation:
>
> Right, I figured that the write side would be enough to catch glaring
> abuse. But sure.
>
> It's a bummer we didn't upgrade the minimum compiler version to 4.9,
> that would've given us _Generic(), which allows one to write this
> slightly less verbose I think.
>

Looking at 5429ef62bcf3 ("compiler/gcc: Raise minimum GCC version for
kernel builds to 4.8"), it seems that the decision of picking gcc 4.8
vs. 4.9 was kinda arbitrary.

Anyway, please continue below.

> How about something disguisting like this then?
>
...
> #define __SEQ_RT	IS_BUILTIN(CONFIG_PREEMPT_RT)
>
> SEQCOUNT_LOCKTYPE(raw_spinlock, raw_spinlock_t,	false,		lock)
> SEQCOUNT_LOCKTYPE(spinlock,	spinlock_t,		__SEQ_RT,	lock)
> SEQCOUNT_LOCKTYPE(rwlock,	rwlock_t,		__SEQ_RT,	lock)
> SEQCOUNT_LOCKTYPE(mutex,	struct mutex,		true,		lock)
> SEQCOUNT_LOCKTYPE(ww_mutex,	struct ww_mutex,	true,		lock->base)
>
> #if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 40900) || defined(__CHECKER__)
>
> #define __seqprop_pick(const_expr, s, locktype, prop, otherwise)	\
> 	__builtin_choose_expr(const_expr,				\
> 			      __seqprop_##locktype##_##prop((void *)(s)), \
> 			      otherwise)
>
> extern void __seqprop_invalid(void);
>
> #define __seqprop(s, prop)								\
> 	__seqprop_pick(__same_type(*(s), seqcount_t), (s), seqcount, prop,		\
> 	  __seqprop_pick(__same_type(*(s), seqcount_raw_spinlock_t), (s), raw_spinlock, prop, \
> 	    __seqprop_pick(__same_type(*(s), seqcount_spinlock_t), (s), spinlock, prop,	\
> 	      __seqprop_pick(__same_type(*(s), seqcount_rwlock_t), (s), rwlock, prop,	\
> 	        __seqprop_pick(__same_type(*(s), seqcount_mutex_t), (s), mutex, prop,	\
> 	          __seqprop_pick(__same_type(*(s), seqcount_ww_mutex_t), (s), ww_mutex, prop, \
> 		    __seqprop_invalid()))))))
>
> #else
>
> #define __seqprop_case(s, locktype, prop) \
> 	seqcount_##locktype##_t: __seqprop_##locktype##_##prop((void *)s)
>
> #define __seqprop(s, prop)					\
> 	_Generic(*(s),						\
> 		 seqcount_t: __seqprop_seqcount_##prop((void*)s),\
> 		 __seqprop_case((s), raw_spinlock, prop),	\
> 		 __seqprop_case((s), spinlock, prop),		\
> 		 __seqprop_case((s), rwlock, prop),		\
> 		 __seqprop_case((s), mutex, prop),		\
> 		 __seqprop_case((s), ww_mutex, prop))
>
> #endif
>
> #define __to_seqcount_t(s)			__seqprop(s, ptr)
> #define __associated_lock_is_preemptible(s)	__seqprop(s, preempt)
> #define __assert_associated_lock_held(s)	__seqprop(s, assert)

Hmm, I'll prototype the whole thing (along with PREEMPT_RT associated
lock()/unlock() as you've mentioned in the other e-mail), and come back.

Honestly, I have a first impression that this is heading into too much
complexity and compaction, but let's finish the whole thing first.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3 06/20] seqlock: Extend seqcount API with associated locks
  @ 2020-07-08 10:43 99%             ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-08 10:43 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Paul E. McKenney,
	Sebastian A. Siewior, Steven Rostedt, LKML

On Wed, Jul 08, 2020 at 11:12:01AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 07, 2020 at 04:37:26PM +0200, Peter Zijlstra wrote:
> > + * Use the ``_irqsave`` and ``_bh`` variants instead if the read side
> > + * ``_bh`` variant of write_seqlock(). Use only if the read side section
> > + * ``_irq`` variant of write_sequnlock(). The write side section of
> > + * ``_irqsave`` variant of write_seqlock(). Use if the read section of
> > + * ``_irqrestore`` variant of write_sequnlock(). The write section of
> > + * ``_bh`` variant of read_seqlock_excl(). Use this variant if the
> > + * ``_bh`` variant of read_sequnlock_excl(). The closed section must've
> > + * ``_irq`` variant of read_seqlock_excl(). Use this only if the
> > + * ``_irq`` variant of read_sequnlock_excl(). The closed section must've
> > + * ``_irqsave`` variant of read_seqlock_excl(). Use this only if the
> > + * ``_irqrestore`` variant of read_sequnlock_excl(). The closed section
> > + * This is the ``_irqsave`` variant of read_seqbegin_or_lock(). Use if
> > + * This is the ``_irqrestore`` variant of done_seqretry(). The read
>
> Can we also get rid of that '' nonsense, the gods of ASCII gifted us "
> for this.

Hehe, why not. I welcome back our ASCII overlords.

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3 01/20] Documentation: locking: Describe seqlock design and usage
  @ 2020-07-07 10:12 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-07-07 10:12 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Paul E. McKenney,
	Sebastian A. Siewior, Steven Rostedt, LKML, Jonathan Corbet,
	linux-doc

On Mon, Jul 06, 2020 at 11:04:39PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 30, 2020 at 07:44:33AM +0200, Ahmed S. Darwish wrote:
> > +Sequence counters (:c:type:`seqcount_t`)
> > +========================================
>
> > +.. code-block:: c
>
> I so hate RST, of course it's C. Also, ISTR Jon saying you can leave
> that all out without issue.

There you go again.

  linux$ git grep 'code-block:: c' | wc -l
  ==>  470

  linux$ git grep ':ref:' | wc -l
  ==>  3171

  linux$ git grep ':c:type:' | wc -l
  ==>  1533

In writing this, Documentation/doc-guide/ was followed, and literally
the thousands of examples above.

But honestly, I don't want to block merging documentation because of
this, and the point of making the docs as readable as possible from text
editors also has merit.

So... I'll just make that file as "RST-lite" as possible.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables
    2020-06-23 15:00 99%   ` Ahmed S. Darwish
@ 2020-06-30  5:59 99%   ` Ahmed S. Darwish
  1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-06-30  5:59 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: mingo, will, tglx, x86, linux-kernel, rostedt, bigeasy, davem,
	sparclinux, mpe, linuxppc-dev, heiko.carstens, linux-s390, linux

Peter Zijlstra wrote:

...

> -#define lockdep_assert_irqs_disabled()	do {			\
> -		WARN_ONCE(debug_locks && !current->lockdep_recursion &&	\
> -			  current->hardirqs_enabled,			\
> -			  "IRQs not disabled as expected\n");		\
> -	} while (0)

...

> +#define lockdep_assert_irqs_disabled()				\
> +do {									\
> +	WARN_ON_ONCE(debug_locks && this_cpu_read(hardirqs_enabled));	\
> +} while (0)

I think it would be nice to keep the "IRQs not disabled as expected"
message. It makes the lockdep splat much more readable.

This is similarly the case for the v3 lockdep preemption macros:

  https://lkml.kernel.org/r/20200630054452.3675847-5-a.darwish@linutronix.de

I did not add a message though to get in-sync with the IRQ macros above.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables
  @ 2020-06-23 16:13 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-06-23 16:13 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: mingo, will, tglx, x86, linux-kernel, rostedt, bigeasy, davem,
	sparclinux, mpe, linuxppc-dev, heiko.carstens, linux-s390, linux

On Tue, Jun 23, 2020 at 05:24:50PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 23, 2020 at 05:00:31PM +0200, Ahmed S. Darwish wrote:
> > On Tue, Jun 23, 2020 at 10:36:52AM +0200, Peter Zijlstra wrote:
> > ...
> > > -#define lockdep_assert_irqs_disabled()	do {				\
> > > -		WARN_ONCE(debug_locks && !current->lockdep_recursion &&	\
> > > -			  current->hardirqs_enabled,			\
> > > -			  "IRQs not disabled as expected\n");		\
> > > -	} while (0)
> > > +#define lockdep_assert_irqs_enabled()					\
> > > +do {									\
> > > +	WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirqs_enabled));	\
> > > +} while (0)
> > >
> >
> > Can we add a small comment on top of lockdep_off(), stating that lockdep
> > IRQ tracking will still be kept after a lockdep_off call?
>
> That would only legitimize lockdep_off(). The only comment I want to put
> on that is: "if you use this, you're doing it wrong'.
>

Well, freshly merged code is using it. For example, KCSAN:

    => f1bc96210c6a ("kcsan: Make KCSAN compatible with lockdep")
    => kernel/kcsan/report.c:

    void kcsan_report(...)
    {
	...
        /*
         * With TRACE_IRQFLAGS, lockdep's IRQ trace state becomes corrupted if
         * we do not turn off lockdep here; this could happen due to recursion
         * into lockdep via KCSAN if we detect a race in utilities used by
         * lockdep.
         */
        lockdep_off();
	...
    }

thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables
  @ 2020-06-23 15:00 99%   ` Ahmed S. Darwish
    2020-06-30  5:59 99%   ` Ahmed S. Darwish
  1 sibling, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2020-06-23 15:00 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: mingo, will, tglx, x86, linux-kernel, rostedt, bigeasy, davem,
	sparclinux, mpe, linuxppc-dev, heiko.carstens, linux-s390, linux

On Tue, Jun 23, 2020 at 10:36:52AM +0200, Peter Zijlstra wrote:
...
> -#define lockdep_assert_irqs_disabled()	do {				\
> -		WARN_ONCE(debug_locks && !current->lockdep_recursion &&	\
> -			  current->hardirqs_enabled,			\
> -			  "IRQs not disabled as expected\n");		\
> -	} while (0)
> +#define lockdep_assert_irqs_enabled()					\
> +do {									\
> +	WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirqs_enabled));	\
> +} while (0)
>

Can we add a small comment on top of lockdep_off(), stating that lockdep
IRQ tracking will still be kept after a lockdep_off call?

thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 01/25] net: core: device_rename: Use rwsem instead of a seqcount
  @ 2020-06-03 14:33 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-06-03 14:33 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Waiman Long, Peter Zijlstra, Ingo Molnar, Will Deacon,
	Thomas Gleixner, Paul E. McKenney, Sebastian A. Siewior,
	Steven Rostedt, LKML, David S. Miller, Jakub Kicinski, netdev

On Wed, May 20, 2020 at 05:51:27AM -0700, Eric Dumazet wrote:
>
> On 5/19/20 11:42 PM, Ahmed S. Darwish wrote:
> > Hello Eric,
> >
> > On Tue, May 19, 2020 at 07:01:38PM -0700, Eric Dumazet wrote:
> >>
> >> On 5/19/20 2:45 PM, Ahmed S. Darwish wrote:
> >>> Sequence counters write paths are critical sections that must never be
> >>> preempted, and blocking, even for CONFIG_PREEMPTION=n, is not allowed.
> >>>
> >>> Commit 5dbe7c178d3f ("net: fix kernel deadlock with interface rename and
> >>> netdev name retrieval.") handled a deadlock, observed with
> >>> CONFIG_PREEMPTION=n, where the devnet_rename seqcount read side was
> >>> infinitely spinning: it got scheduled after the seqcount write side
> >>> blocked inside its own critical section.
> >>>
> >>> To fix that deadlock, among other issues, the commit added a
> >>> cond_resched() inside the read side section. While this will get the
> >>> non-preemptible kernel eventually unstuck, the seqcount reader is fully
> >>> exhausting its slice just spinning -- until TIF_NEED_RESCHED is set.
> >>>
> >>> The fix is also still broken: if the seqcount reader belongs to a
> >>> real-time scheduling policy, it can spin forever and the kernel will
> >>> livelock.
> >>>
> >>> Disabling preemption over the seqcount write side critical section will
> >>> not work: inside it are a number of GFP_KERNEL allocations and mutex
> >>> locking through the drivers/base/ :: device_rename() call chain.
> >>>
> >>> From all the above, replace the seqcount with a rwsem.
> >>>
> >>> Fixes: 5dbe7c178d3f (net: fix kernel deadlock with interface rename and netdev name retrieval.)
> >>> Fixes: 30e6c9fa93cf (net: devnet_rename_seq should be a seqcount)
> >>> Fixes: c91f6df2db49 (sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name)
> >>> Cc: <stable@vger.kernel.org>
> >>> Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
> >>> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> >>> ---
> >>>  net/core/dev.c | 30 ++++++++++++------------------
> >>>  1 file changed, 12 insertions(+), 18 deletions(-)
> >>>
> >>
> >> Seems fine to me, assuming rwsem prevent starvation of the writer.
> >>
> >
> > Thanks for the review.
> >
> > AFAIK, due to 5cfd92e12e13 ("locking/rwsem: Adaptive disabling of reader
> > optimistic spinning"), using a rwsem shouldn't lead to writer starvation
> > in the contended case.
>
> Hmm this was in linux-5.3, so very recent stuff.
>
> Has this patch been backported to stable releases ?
>
> With all the Fixes: tags you added, stable teams will backport this
> networking patch to all stable versions.
>
> Do we have a way to tune a dedicare rwsem to 'give preference to the
> (unique in this case) writer" over a myriad of potential readers ?
>

I was wrong in referencing the commit 5cfd92e12e13 above.

Before and after that commit, once a rwsem writer is blocking, all
subsequent readers will block until that writer makes progress.

Given that behavior, and that the read section is already quite short, I
don't think there's any danger incurred on writers here.

(a v2 will be sent shortly, fixing the error found Dan/kbuild-bot.)

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 07/25] lockdep: Add preemption disabled assertion API
  @ 2020-05-26  9:45 99%               ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-05-26  9:45 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Sebastian A. Siewior, Ingo Molnar, Will Deacon, Thomas Gleixner,
	Paul E. McKenney, Steven Rostedt, LKML

On Tue, May 26, 2020 at 10:13:50AM +0200, Peter Zijlstra wrote:
> On Tue, May 26, 2020 at 02:52:31AM +0200, Ahmed S. Darwish wrote:
> > Peter Zijlstra <peterz@infradead.org> wrote:
>
> > > +#define lockdep_assert_irqs_enabled()					\
> > > +do {									\
> > > +	WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirqs_enabled));	\
> > > +} while (0)
> > >
> >
> > Given that lockdep_off() is defined at lockdep.c as:
> >
> >   void lockdep_off(void)
> >   {
> >         current->lockdep_recursion += LOCKDEP_OFF;
> >   }
> >
> > This would imply that all of the macros:
> >
> >   - lockdep_assert_irqs_enabled()
> >   - lockdep_assert_irqs_disabled()
> >   - lockdep_assert_in_irq()
> >   - lockdep_assert_preemption_disabled()
> >   - lockdep_assert_preemption_enabled()
> >
> > will do the lockdep checks *even if* lockdep_off() was called.
> >
> > This doesn't sound right. Even if all of the above macros call sites
> > didn't care about lockdep_off()/on(), it is semantically incoherent.
>
> lockdep_off() is an abomination and really should not exist.
>
> That dm-cache-target.c thing, for example, is atrocious shite that will
> explode on -rt. Whoever wrote that needs a 'medal'.
>
> People using it deserve all the pain they get.
>
> Also; IRQ state _should_ be tracked irrespective of tracking lock
> dependencies -- I see that that currently isn't entirely the case, lemme
> go fix that.
>

Exactly, currently all the lockdep IRQ checks gets nullified if
lockdep_off() is called. That was the source of my confusion.

If you'll have any extra patches on this, I can also queue them in the
next iteration of this series, before this patch.

Thanks a lot,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 07/25] lockdep: Add preemption disabled assertion API
  @ 2020-05-26  0:52 99%           ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2020-05-26  0:52 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Sebastian A. Siewior, Ingo Molnar, Will Deacon, Thomas Gleixner,
	Paul E. McKenney, Steven Rostedt, LKML

Peter Zijlstra <peterz@infradead.org> wrote:
> On Sun, May 24, 2020 at 12:41:32AM +0200, Peter Zijlstra wrote:
> > On Sat, May 23, 2020 at 04:59:42PM +0200, Sebastian A. Siewior wrote:
> > >
> > > Any "static inline" in the header file using
> > > lockdep_assert_preemption_disabled() will tro to complain about missing
> > > current-> define. But yes, it will work otherwise.
> >
> > Because...? /me rummages around.. Ah you're proposing sticking this in
> > seqcount itself and then header hell.
> >
> > Moo.. ok I'll go have another look on Monday.
>
> How's this?
>

This will work for my case as current-> is no longer referenced by the
lockdep macros. Please continue below though.

...

> -#define lockdep_assert_irqs_enabled()	do {				\
> -		WARN_ONCE(debug_locks && !current->lockdep_recursion &&	\
> -			  !current->hardirqs_enabled,			\
> -			  "IRQs not enabled as expected\n");		\
> -	} while (0)
> +DECLARE_PER_CPU(int, hardirqs_enabled);
> +DECLARE_PER_CPU(int, hardirq_context);
>
> -#define lockdep_assert_irqs_disabled()	do {				\
> -		WARN_ONCE(debug_locks && !current->lockdep_recursion &&	\
> -			  current->hardirqs_enabled,			\
> -			  "IRQs not disabled as expected\n");		\
> -	} while (0)
> +#define lockdep_assert_irqs_enabled()					\
> +do {									\
> +	WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirqs_enabled));	\
> +} while (0)
>

Given that lockdep_off() is defined at lockdep.c as:

  void lockdep_off(void)
  {
        current->lockdep_recursion += LOCKDEP_OFF;
  }

This would imply that all of the macros:

  - lockdep_assert_irqs_enabled()
  - lockdep_assert_irqs_disabled()
  - lockdep_assert_in_irq()
  - lockdep_assert_preemption_disabled()
  - lockdep_assert_preemption_enabled()

will do the lockdep checks *even if* lockdep_off() was called.

This doesn't sound right. Even if all of the above macros call sites
didn't care about lockdep_off()/on(), it is semantically incoherent.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 01/25] net: core: device_rename: Use rwsem instead of a seqcount
  @ 2020-05-25 16:22 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-05-25 16:22 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: kbuild, Peter Zijlstra, Ingo Molnar, Will Deacon, lkp,
	kbuild-all, Thomas Gleixner, Paul E. McKenney,
	Sebastian A. Siewior, Steven Rostedt, LKML, Jakub Kicinski,
	netdev

On Wed, May 20, 2020 at 05:37:07PM +0300, Dan Carpenter wrote:
...
>
> smatch warnings:
> net/core/dev.c:953 netdev_get_name() warn: inconsistent returns 'devnet_rename_sem'.
>
...
>
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  935  int netdev_get_name(struct net *net, char *name, int ifindex)
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  936  {
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  937  	struct net_device *dev;
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  938
> 2354e271ada778b Ahmed S. Darwish 2020-05-19  939  	down_read(&devnet_rename_sem);
>                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> 2354e271ada778b Ahmed S. Darwish 2020-05-19  940
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  941  	rcu_read_lock();
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  942  	dev = dev_get_by_index_rcu(net, ifindex);
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  943  	if (!dev) {
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  944  		rcu_read_unlock();
> 5dbe7c178d3f0a4 Nicolas Schichan 2013-06-26  945  		return -ENODEV;
>                                                               ^^^^^^^^^^^^^^

Oh, shouldn't have missed that. Will fix in v2.

Thanks,

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 09/25] Documentation: locking: Describe seqlock design and usage
  @ 2020-05-25 11:02 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-05-25 11:02 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Thomas Gleixner,
	Paul E. McKenney, Sebastian A. Siewior, LKML, Jonathan Corbet,
	linux-doc

Ahmed S. Darwish <a.darwish@linutronix.de> wrote:
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> > > Peter Zijlstra <peterz@infradead.org> wrote:
...
> > >
> > > So I really really hate that... I _much_ prefer code comments to crappy
> > > documents.
> >
> > Agreed. Comments are much less likely to bitrot than documents. The
> > farther away the documentation is from the code, the quicker it becomes
> > stale.
> >
> > It's fine to add "See Documentation/..." but please don't *ever* remove
> > comments that's next to the actual code.
...
>
> Then, the brlock comment:
>
>     This is not as cache friendly as brlock. Also, this may not work
>     well for data that contains pointers, because any writer could
>     invalidate a pointer that a reader was following.
>
> was removed not because it's moved to Documentation/locking/seqlock.rst,
> but because it's obsolete: 0f6ed63b1707 ("no need to keep brlock macros
> anymore...").
>

Hmm, the part about not including pointers is only mentiond in the RST
file though, and not at seqlock.h.

Anyway, ACK, I'll beef up the comments at seqlock.h and make sure they
are self-contained.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 04/25] block: nr_sects_write(): Disable preemption on seqcount write
       [not found]       ` <20200522001237.A00E8206BE@mail.kernel.org>
@ 2020-05-25 10:12 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-05-25 10:12 UTC (permalink / raw)
  To: Sasha Levin
  Cc: Peter Zijlstra, Thomas Gleixner, Sebastian A. Siewior, stable,
	Jens Axboe, Christoph Hellwig, linux-block, LKML

Sasha Levin <sashal@kernel.org> wrote:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: c83f6bf98dc1 ("block: add partition resize function to blkpg ioctl").
>
> The bot has tested the following trees: v5.6.13, v5.4.41, v4.19.123, v4.14.180, v4.9.223, v4.4.223.
>
> v5.6.13: Failed to apply! Possible dependencies:
...
> v5.4.41: Failed to apply! Possible dependencies:
...
> v4.19.123: Failed to apply! Possible dependencies:
...
> v4.14.180: Failed to apply! Possible dependencies:
...
> v4.9.223: Failed to apply! Possible dependencies:
...
> v4.4.223: Failed to apply! Possible dependencies:
...
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>

The v5.7-rc1 commit 581e26004a09 ("block: move block layer internals out
of include/linux/genhd.h") moved the part_nr_sects_write() static inline
function from include/linux/genhd.h to block/blk.h.

After review, I'll send a rebased patch to stable.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 04/25] block: nr_sects_write(): Disable preemption on seqcount write
  @ 2020-05-25  9:56 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2020-05-25  9:56 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar, Will Deacon, Thomas Gleixner, Paul E. McKenney,
	Sebastian A. Siewior, Steven Rostedt, LKML, Jens Axboe,
	Phillip Susi, Vivek Goyal, linux-block

Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, May 19, 2020 at 11:45:26PM +0200, Ahmed S. Darwish wrote:
> > For optimized block readers not holding a mutex, the "number of sectors"
> > 64-bit value is protected from tearing on 32-bit architectures by a
> > sequence counter.
> >
> > Disable preemption before entering that sequence counter's write side
> > critical section. Otherwise, the read side can preempt the write side
> > section and spin for the entire scheduler tick. If the reader belongs to
> > a real-time scheduling class, it can spin forever and the kernel will
> > livelock.
> >
> > Fixes: c83f6bf98dc1 ("block: add partition resize function to blkpg ioctl")
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
> > Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> >  block/blk.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/block/blk.h b/block/blk.h
> > index 0a94ec68af32..151f86932547 100644
> > --- a/block/blk.h
> > +++ b/block/blk.h
> > @@ -470,9 +470,11 @@ static inline sector_t part_nr_sects_read(struct hd_struct *part)
> >  static inline void part_nr_sects_write(struct hd_struct *part, sector_t size)
> >  {
> >  #if BITS_PER_LONG==32 && defined(CONFIG_SMP)
> > +	preempt_disable();
> >  	write_seqcount_begin(&part->nr_sects_seq);
> >  	part->nr_sects = size;
> >  	write_seqcount_end(&part->nr_sects_seq);
> > +	preempt_enable();
> >  #elif BITS_PER_LONG==32 && defined(CONFIG_PREEMPTION)
> >  	preempt_disable();
> >  	part->nr_sects = size;
>
> This does look like something that include/linux/u64_stats_sync.h could
> help with.

Correct.

I just felt though that this would be too much for a 'Cc: stable' patch.

In another (in-progress) seqlock.h patch series, all of the seqcount_t
call sites that are used for 64-bit values tearing protection on 32-bit
kernels are transformed to the u64_stats_sync.h API.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v1 01/25] net: core: device_rename: Use rwsem instead of a seqcount
  @ 2020-05-20  6:42 99%     ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2020-05-20  6:42 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Waiman Long, Peter Zijlstra, Ingo Molnar, Will Deacon,
	Thomas Gleixner, Paul E. McKenney, Sebastian A. Siewior,
	Steven Rostedt, LKML, David S. Miller, Jakub Kicinski, netdev

Hello Eric,

On Tue, May 19, 2020 at 07:01:38PM -0700, Eric Dumazet wrote:
>
> On 5/19/20 2:45 PM, Ahmed S. Darwish wrote:
> > Sequence counters write paths are critical sections that must never be
> > preempted, and blocking, even for CONFIG_PREEMPTION=n, is not allowed.
> >
> > Commit 5dbe7c178d3f ("net: fix kernel deadlock with interface rename and
> > netdev name retrieval.") handled a deadlock, observed with
> > CONFIG_PREEMPTION=n, where the devnet_rename seqcount read side was
> > infinitely spinning: it got scheduled after the seqcount write side
> > blocked inside its own critical section.
> >
> > To fix that deadlock, among other issues, the commit added a
> > cond_resched() inside the read side section. While this will get the
> > non-preemptible kernel eventually unstuck, the seqcount reader is fully
> > exhausting its slice just spinning -- until TIF_NEED_RESCHED is set.
> >
> > The fix is also still broken: if the seqcount reader belongs to a
> > real-time scheduling policy, it can spin forever and the kernel will
> > livelock.
> >
> > Disabling preemption over the seqcount write side critical section will
> > not work: inside it are a number of GFP_KERNEL allocations and mutex
> > locking through the drivers/base/ :: device_rename() call chain.
> >
> > From all the above, replace the seqcount with a rwsem.
> >
> > Fixes: 5dbe7c178d3f (net: fix kernel deadlock with interface rename and netdev name retrieval.)
> > Fixes: 30e6c9fa93cf (net: devnet_rename_seq should be a seqcount)
> > Fixes: c91f6df2db49 (sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name)
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de>
> > Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> >  net/core/dev.c | 30 ++++++++++++------------------
> >  1 file changed, 12 insertions(+), 18 deletions(-)
> >
>
> Seems fine to me, assuming rwsem prevent starvation of the writer.
>

Thanks for the review.

AFAIK, due to 5cfd92e12e13 ("locking/rwsem: Adaptive disabling of reader
optimistic spinning"), using a rwsem shouldn't lead to writer starvation
in the contended case.

--
Ahmed S. Darwish
Linutronix GmbH

^ permalink raw reply	[relevance 99%]

* Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2()
  @ 2019-09-26 21:11 99%                                                   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2019-09-26 21:11 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Florian Weimer, Linus Torvalds, Lennart Poettering,
	Theodore Y. Ts'o, Eric W. Biederman, Alexander E. Patrakov,
	Michael Kerrisk, Willy Tarreau, Matthew Garrett, lkml,
	Ext4 Developers List, Linux API, linux-man

On Mon, Sep 23, 2019 at 11:33:21AM -0700, Andy Lutomirski wrote:
> On Fri, Sep 20, 2019 at 11:07 PM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Linus Torvalds:
> >
> > > Violently agreed. And that's kind of what the GRND_EXPLICIT is really
> > > aiming for.
> > >
> > > However, it's worth noting that nobody should ever use GRND_EXPLICIT
> > > directly. That's just the name for the bit. The actual users would use
> > > GRND_INSECURE or GRND_SECURE.
> >
> > Should we switch glibc's getentropy to GRND_EXPLICIT?  Or something
> > else?
> >
> > I don't think we want to print a kernel warning for this function.
> >
> 
> Contemplating this question, I think the answer is that we should just
> not introduce GRND_EXPLICIT or anything like it.  glibc is going to
> have to do *something*, and getentropy() is unlikely to just go away.
> The explicitly documented semantics are that it blocks if the RNG
> isn't seeded.
> 
> Similarly, FreeBSD has getrandom():
> 
> https://www.freebsd.org/cgi/man.cgi?query=getrandom&sektion=2&manpath=freebsd-release-ports
> 
> and if we make getrandom(..., 0) warn, then we have a situation where
> the *correct* (if regrettable) way to use the function on FreeBSD
> causes a warning on Linux.
> 
> Let's just add GRND_INSECURE, make the blocking mode work better, and,
> if we're feeling a bit more adventurous, add GRND_SECURE_BLOCKING as a
> better replacement for 0, ...

This is what's now done in the just-submitted V5, except the "make the
blocking mode work better" part:

    https://lkml.kernel.org/r/20190926204217.GA1366@pc

It's a very conservative patch so far IMHO (minus the loud warning).

Thanks,
--
Ahmed Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2()
  @ 2019-09-20 17:56 99%                                         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2019-09-20 17:56 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Linus Torvalds, Lennart Poettering, Theodore Y. Ts'o,
	Eric W. Biederman, Alexander E. Patrakov, Michael Kerrisk,
	Matthew Garrett, lkml, linux-ext4, linux-api, linux-man

On Fri, Sep 20, 2019 at 07:26:09PM +0200, Willy Tarreau wrote:
> Hi Ahmed,
> 
> On Fri, Sep 20, 2019 at 03:46:09PM +0200, Ahmed S. Darwish wrote:
> > Problem is, glibc is still *really* slow in adopting linux syscall
> > wrappers, so I'm not optimistic about that...
> >
> > I still see the new system call as the sanest path, even provided
> > the cost of a new syscall number..
> 
> New syscalls are always a pain to deal with in userland, because when
> they are introduced, everyone wants them long before they're available
> in glibc. So userland has to define NR_xxx for each supported arch and
> to perform the call itself.
> 
> With flags adoption is instantaneous. Just #ifndef/#define, check if
> the flag is supported and that's done. The only valid reason for a new
> syscall is when the API changes (e.g. one extra arg, a la accept4()),
> which doesn't seem to be the case here. Otherwise please by all means
> avoid this in general.
> 

I see. Thanks a lot for the explanation above :)

--
Ahmed Darwish

^ permalink raw reply	[relevance 99%]

* Re: Linux 5.3-rc8
  @ 2019-09-16 19:53 99%                                               ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2019-09-16 19:53 UTC (permalink / raw)
  To: Theodore Y. Ts'o
  Cc: Linus Torvalds, Willy Tarreau, Vito Caputo, Lennart Poettering,
	Andreas Dilger, Jan Kara, Ray Strode, William Jon McCann,
	Alexander E. Patrakov, zhangjs, linux-ext4, lkml

On Mon, Sep 16, 2019 at 01:21:17PM -0400, Theodore Y. Ts'o wrote:
> On Mon, Sep 16, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
> > So the semantics that getrandom() should have had are:
> > 
> >  getrandom(0) - just give me reasonable random numbers for any of a
> > million non-strict-long-term-security use (ie the old urandom)
> > 
> >     - the nonblocking flag makes no sense here and would be a no-op
> 
> That change is what I consider highly problematic.  There are a *huge*
> number of applications which use cryptography which assumes that
> getrandom(0) means, "I'm guaranteed to get something safe
> cryptographic use".  Changing his now would expose a very large number
> of applications to be insecure.  Part of the problem here is that
> there are many different actors.  There is the application or
> cryptographic library developer, who may want to be sure they have
> cryptographically secure random numbers.  They are the ones who will
> select getrandom(0).
> 
> Then you have the distribution or consumer-grade electronics
> developers who may choose to run them too early in some init script or
> systemd unit files.  And some of these people may do something stupid,
> like run things too early, or omit the a hardware random number
> generator in their design, even though it's for a security critical
> purpose (say, a digital wallet for bitcoin).

Ted, you're really the expert here. My apologies though, every time I
see the words "too early" I get a cramp... Please check my earlier
reply:

    https://lkml.kernel.org/r/20190912034421.GA2085@darwi-home-pc

Specifically the trace_printk log of all the getrandom(2) calls
during an standard Archlinux boot...

where is the "too early" boundary there? It's undefinable.

You either have entropy, or you don't. And if you don't, it will stay
like this forever, because if you had, you wouldn't have blocked in
the first place...

Thanks,

--
Ahmed Darwish
http://darwish.chasingpointers.com

^ permalink raw reply	[relevance 99%]

* Re: Linux 5.3-rc8
  @ 2019-09-15  7:27 99%                             ` Ahmed S. Darwish
    1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2019-09-15  7:27 UTC (permalink / raw)
  To: Lennart Poettering
  Cc: Linus Torvalds, Theodore Y. Ts'o, Andreas Dilger, Jan Kara,
	Ray Strode, William Jon McCann, Alexander E. Patrakov, zhangjs,
	linux-ext4, lkml

On Sun, Sep 15, 2019 at 08:51:42AM +0200, Lennart Poettering wrote:
> On Sa, 14.09.19 09:30, Linus Torvalds (torvalds@linux-foundation.org) wrote:
[...]
> 
> And please don't break /dev/urandom again. The above code is the ony
> way I see how we can make /dev/urandom-derived swap encryption safe,
> and the only way I can see how we can sanely write a valid random seed
> to disk after boot.
>

Any hope in making systemd-random-seed(8) credit that "random seed
from previous boot" file, through RNDADDENTROPY, *by default*?

Because of course this makes the problem reliably go away on my system
too (as discussed in the original bug report, but you were not CCed).

I know that by v243, just released 12 days ago, this can be optionally
done through SYSTEMD_RANDOM_SEED_CREDIT=1. I wonder though if it can
ever be done by default, just like what the BSDs does... This would
solve a big part of the current problem.

> Lennart

thanks,

-- 
darwi
http://darwish.chasingpointers.com

^ permalink raw reply	[relevance 99%]

* Re: Linux 5.3-rc8
  2019-09-11 21:41 99%             ` Ahmed S. Darwish
@ 2019-09-11 22:37 99%               ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2019-09-11 22:37 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Theodore Y. Ts'o, Andreas Dilger, Jan Kara, Ray Strode,
	William Jon McCann, zhangjs, linux-ext4, lkml

On Wed, Sep 11, 2019 at 11:41:44PM +0200, Ahmed S. Darwish wrote:
> On Wed, Sep 11, 2019 at 05:45:38PM +0100, Linus Torvalds wrote:
[...]
> >
> > Well, even on a PC, sometimes rdrand just isn't there. AMD has screwed
> > it up a few times, and older Intel chips just don't have it.
> > 
> > So I'd be inclined to either lower the limit regardless -
> 
> ACK :)
> 
> > and perhaps make the "user space asked for randomness much too
> > early" be a big *warning* instead of being a basically fatal hung
> > machine?
> 
> Hmmm, regarding "randomness request much too early", how much is time
> really a factor here?
> 
> I tested leaving the machine even for 15+ minutes, and it still didn't
> continue booting: the boot is practically blocked forever...
> 
> Or is the thoery that hopefully once the machine is un-stuck, more
> sources of entropy will be available? If that's the case, then
> possibly (rate-limited):
> 
>   "urandom: process XX asked for YY bytes. CRNG not yet initialized"
>
     ^
     getrandom: ....

(since urandom always succeeds, even if CRNG is not inited, and
 it already prints a very similar warning in that case anyway..)

thanks,
--darwi

^ permalink raw reply	[relevance 99%]

* Re: Linux 5.3-rc8
  @ 2019-09-11 21:41 99%             ` Ahmed S. Darwish
  2019-09-11 22:37 99%               ` Ahmed S. Darwish
    1 sibling, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2019-09-11 21:41 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Theodore Y. Ts'o, Andreas Dilger, Jan Kara, Ray Strode,
	William Jon McCann, zhangjs, linux-ext4, lkml

On Wed, Sep 11, 2019 at 05:45:38PM +0100, Linus Torvalds wrote:
> On Wed, Sep 11, 2019 at 5:07 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> > >
> > > Ted, comments? I'd hate to revert the ext4 thing just because it
> > > happens to expose a bad thing in user space.
> >
> > Unfortuantely, I very much doubt this is going to work.  That's
> > because the add_disk_randomness() path is only used for legacy
> > /dev/random [...]
> >
> > Also, because by default, the vast majority of disks have
> > /sys/block/XXX/queue/add_random set to zero by default.
> 
> Gaah. I was looking at the input randomness, since I thought that was
> where the added randomness that Ahmed got things to work with came
> from.
> 
> And that then made me just look at the legacy disk randomness (for the
> obvious disk IO reasons) and I didn't look further.
>

Yup, I confirm that the quick patch kept the situation as-is. I was
going to debug why, but now we know the answer..

> > So the the way we get entropy these days for initializing the CRNG is
> > via the add_interrupt_randomness() path, where do something really
> > fast, and we assume that we get enough uncertainity from 8 interrupts
> > to give us one bit of entropy (64 interrupts to give us a byte of
> > entropy), and that we need 512 bits of entropy to consider the CRNG
> > fully initialized.  (Yeah, there's a lot of conservatism in those
> > estimates, and so what we could do is decide to say, cut down the
> > number of bits needed to initialize the CRNG to be 256 bits, since
> > that's the size of the CHACHA20 cipher.)
> 
> So that's 4k interrupts if I counted right, and yeah, maybe Ahmed was
> just close enough before, and the merging of the inode table IO then
> took him below that limit.
>
> > Ultimately, though, we need to find *some* way to fix userspace's
> > assumptions that they can always get high quality entropy in early
> > boot, or we need to get over people's distrust of Intel and RDRAND.
>
> Well, even on a PC, sometimes rdrand just isn't there. AMD has screwed
> it up a few times, and older Intel chips just don't have it.
> 
> So I'd be inclined to either lower the limit regardless -

ACK :)

> and perhaps make the "user space asked for randomness much too
> early" be a big *warning* instead of being a basically fatal hung
> machine?

Hmmm, regarding "randomness request much too early", how much is time
really a factor here?

I tested leaving the machine even for 15+ minutes, and it still didn't
continue booting: the boot is practically blocked forever...

Or is the thoery that hopefully once the machine is un-stuck, more
sources of entropy will be available? If that's the case, then
possibly (rate-limited):

  "urandom: process XX asked for YY bytes. CRNG not yet initialized"

> Linus

thanks,

--
darwi
http://darwish.chasingpointers.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] printk: kmsg_dump: Mark registered flag as private
  @ 2019-03-12 20:05 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2019-03-12 20:05 UTC (permalink / raw)
  To: Sergey Senozhatsky; +Cc: Petr Mladek, Steven Rostedt, John Ogness, linux-kernel

Hi,

On Mon, Mar 11, 2019 at 09:49:05PM +0900, Sergey Senozhatsky wrote:
> On (03/10/19 21:03), Ahmed S. Darwish wrote:
> > The 'registered' flag is internally used by kmsg_dump_register()
> > and kmsg_dump_unregister() to track multiple registrations of the
> > same dumper.
> >
> > It's protected by printk's internal dump_list_lock, and must thus
> > be accessed only from there. Mark it as private.
> >
> > Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
> > ---
> >  include/linux/kmsg_dump.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h
> > index 2e7a1e032c71..7c08cb58259a 100644
> > --- a/include/linux/kmsg_dump.h
> > +++ b/include/linux/kmsg_dump.h
> > @@ -36,7 +36,7 @@ enum kmsg_dump_reason {
> >   * @dump:	Call into dumping code which will retrieve the data with
> >   * 		through the record iterator
> >   * @max_reason:	filter for highest reason number that should be dumped
> > - * @registered:	Flag that specifies if this is already registered
> > + * @registered:	Flag that specifies if this is already registered (private)
> >   */
> >  struct kmsg_dumper {
> >  	struct list_head list;
>
>
> Do we really do this thing?
>
>
> $ git grep "(private)" include/linux/
> include/linux/kmsg_dump.h: * @list:     Entry in the dumper list (private)
> include/linux/uwb.h: * specific (private) DevAddr (UWB_RSV_TARGET_DEVADDR).
>

Hmmm, while writing a kmsg_dumper for [1], I noticed that struct
kmsg_dumper is:

    /**
     * struct kmsg_dumper - kernel crash message dumper structure
     * @list:        Entry in the dumper list (private)  <== *
     * ...
     * @registered:  Flag that specifies if this is already registered
     */
    struct kmsg_dumper {
    	struct list_head list;
    	...
    	bool registered;
    	/* private state of the kmsg iterator */         <== *
    	...
    };

_All_ private members are annotated (<== *), so this gave the
impression that 'bool registered' was public..

Then I discovered from printk.c code that it's actually private,
and protected by the printk's internal dump_list_lock...

So this trivial patch was submitted for consistency.

thanks,

[1] https://lore.kernel.org/lkml/20190310013142.GA3376@darwi-home-pc

--
darwi
http://darwish.chasingpointers.com

^ permalink raw reply	[relevance 99%]

* Re: DRM-based Oops viewer
  @ 2019-03-11 23:39 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2019-03-11 23:39 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Jani Nikula, David Airlie, Joonas Lahtinen, Rodrigo Vivi,
	Alex Deucher, Christian König, David Zhou, Ard Biesheuvel,
	Matt Fleming, Linus Torvalds, Greg Kroah-Hartman, John Ogness,
	dri-devel, linux-kernel

On Mon, Mar 11, 2019 at 02:49:41PM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 11:04:19AM +0200, Jani Nikula wrote:
> > On Sun, 10 Mar 2019, "Ahmed S. Darwish" <darwish.07@gmail.com> wrote:
> > > Hello DRM/UEFI maintainers,
> > >
> > > Several years ago, I wrote a set of patches to dump the kernel
> > > log to disk upon panic -- through BIOS INT 0x13 services. [1]
> > >
> > > The overwhelming response was that it's unsafe to do this in a
> > > generic manner. Linus proposed a video-based viewer instead: [2]
> > >
> > >     If you want to do the BIOS services thing, do it for video: copy the
> > >     oops to low RAM, return to real mode, re-run the graphics card POST
> > >     routines to initialize text-mode, and use the BIOS to print out the
> > >     oops.  That is WAY less scary than writing to disk.
> > >
> > > Of course it's 2019 now though, and it's quite known that
> > > Intel is officially obsoleting the PC/AT BIOS by 2020.. [3]
> > >
> > > Researching whether this can be done from UEFI, it was also clear
> > > that UEFI "Runtime Services" do not provide any re-initialization
> > > routines. [4]
> > >
> > > The maximum possible that UEFI can provide is a GOP-provided
> > > framebuffer that's ready to use by the OS -- even after the UEFI
> > > boot phase is marked as done through ExitBootServices(). [5]
> > >
> > > Of course, once native drivers like i915 or radeon take over,
> > > such a framebuffer is toast... [6]
> > >
> > > Thus a possible remaining option, is to display the oops through
> > > "minimal" DRM drivers provided for each HW variant... Since
> > > these special drivers will run only and fully under a panic()
> > > context though, several constraints exist:
> > >
> > >   - The code should be fully synchronous (irqs are disabled)
> > >   - It should not allocate any dynamic memory
> > >   - It should make minimal assumptions about HW state
> > >   - It should not chain into any other kernel subsystem
> > >   - It has ample freedom to use delay-based loops and the
> > >     like, the kernel is already dead.
> > >
> > > How feasible is it to have such a special "DRM viewoops"
> > > framework + its minimal drivers in the kernel?
> >
> > Please first better define what you want to achieve.
> >
> > Do you want to store the dmesg or oops (like your original series
> > suggests) or do you want to display the oops? Do you want the facility
> > to be functioning at all times, or only when specifically requested in
> > advance by the user? If you want to display the oops, do you want it to
> > also work when the display is disabled at the time of the oops? What if
> > the display is at attached to a port on a dock?
> >
> > There's at least kdump, ramoops, and netconsole that can be used to
> > achieve some of what you want. How do they fall short for you?
>
> Assuming the use-case is to get an oops to display on a kms driver, we do
> have a fairly comprehensive plan of what that's should look like:
>
> https://dri.freedesktop.org/docs/drm/gpu/todo.html#make-panic-handling-work
>
> This takes into account all the failed previous attempts at trying to get
> an oops to display. It's conceptually a match with your viewoops framework
> I think.

Thanks a lot Daniel for the reference! Yup, this is a conceptual
match indeed!

It's great to know that at the maintainer level there is some
agreement on, awareness of, and plans for, the general topic...

I'll jump to Noralf Trønnes's just-posted patches then and see how
to move from there :)

all the best,

--darwi
http://darwish.chasingpointers.com

^ permalink raw reply	[relevance 99%]

* [PATCH] printk: kmsg_dump: Mark registered flag as private
@ 2019-03-10 20:03 99% Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2019-03-10 20:03 UTC (permalink / raw)
  To: Petr Mladek, Sergey Senozhatsky; +Cc: Steven Rostedt, John Ogness, linux-kernel

The 'registered' flag is internally used by kmsg_dump_register()
and kmsg_dump_unregister() to track multiple registrations of the
same dumper.

It's protected by printk's internal dump_list_lock, and must thus
be accessed only from there. Mark it as private.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
 include/linux/kmsg_dump.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kmsg_dump.h b/include/linux/kmsg_dump.h
index 2e7a1e032c71..7c08cb58259a 100644
--- a/include/linux/kmsg_dump.h
+++ b/include/linux/kmsg_dump.h
@@ -36,7 +36,7 @@ enum kmsg_dump_reason {
  * @dump:	Call into dumping code which will retrieve the data with
  * 		through the record iterator
  * @max_reason:	filter for highest reason number that should be dumped
- * @registered:	Flag that specifies if this is already registered
+ * @registered:	Flag that specifies if this is already registered (private)
  */
 struct kmsg_dumper {
 	struct list_head list;
--
2.21.0

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 01/10] procfs: add smack subdir to attrs
  @ 2018-09-11 23:45 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2018-09-11 23:45 UTC (permalink / raw)
  To: Casey Schaufler
  Cc: LSM, James Morris, LKM, SE Linux, John Johansen, Kees Cook,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey

On Tue, Sep 11, 2018 at 09:41:32AM -0700, Casey Schaufler wrote:
> Back in 2007 I made what turned out to be a rather serious
> mistake in the implementation of the Smack security module.
> The SELinux module used an interface in /proc to manipulate
> the security context on processes. Rather than use a similar
> interface, I used the same interface. The AppArmor team did
> likewise. Now /proc/.../attr/current will tell you the
> security "context" of the process, but it will be different
> depending on the security module you're using.
>
> This patch provides a subdirectory in /proc/.../attr for
> Smack. Smack user space can use the "current" file in
> this subdirectory and never have to worry about getting
> SELinux attributes by mistake. Programs that use the
> old interface will continue to work (or fail, as the case
> may be) as before.
>

Did downstream distributions already merge the stacking patches on
their own?

Got a little-bit confused after reading the log above; I already see
this in in Ubuntu 18.04.1 LTS, v4.15.0-33-generic:

    $ tree /proc/self/attr/
    /proc/self/attr/
    ├── apparmor
    │   ├── current
    │   ├── exec
    │   └── prev
    ├── current
    ├── display_lsm
    ├── exec
    ├── fscreate
    ├── keycreate
    ├── prev
    ├── selinux
    │   ├── current
    │   ├── exec
    │   ├── fscreate
    │   ├── keycreate
    │   ├── prev
    │   └── sockcreate
    ├── smack
    │   └── current
    └── sockcreate

Thanks,

--
Darwi
http://darwish.chasingpointers.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 11/13] proc: readdir /proc/*/task
  @ 2018-08-28 12:36 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2018-08-28 12:36 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: akpm, linux-kernel

On Tue, Aug 28, 2018 at 02:15:01AM +0300, Alexey Dobriyan wrote:
> ---
>  fs/proc/base.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

Missing description and S-o-b. Further comments below..

> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 33f444721965..668e465c86b3 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -3549,11 +3549,11 @@ static int proc_task_readdir(struct file *file, struct dir_context *ctx)
>  	for (task = first_tid(proc_pid(inode), tid, ctx->pos - 2, ns);
>  	     task;
>  	     task = next_tid(task), ctx->pos++) {
> -		char name[10 + 1];
> -		unsigned int len;
> +		char name[10], *p = name + sizeof(name);
> +

Multiple issues:

- len should be 11, as was in the original code
  (0xffffffff = 4294967295, 10 letters)

- while we're at it, let's use a constant for the '11' instead of
  mysterious magic numbers

- 'p' is clearly overflowing the stack here

>  		tid = task_pid_nr_ns(task, ns);
> -		len = snprintf(name, sizeof(name), "%u", tid);
> -		if (!proc_fill_cache(file, ctx, name, len,
> +		p = _print_integer_u32(p, tid);
> +		if (!proc_fill_cache(file, ctx, p, name + sizeof(name) - p,

You're replacing snprintf() code __that did proper len checking__
with code that does not. That's not good.

I can't see how the fourth proc_fill_cache() parameter, ``name +
sizeof(name)'' safely ever replace the original 'len' parameter.
It's a pointer value .. (!)

Overall this looks like a broken patch submitted by mistake.

Thanks,

-- 
Darwish
http://darwish.chasingpointers.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v5 1/2] can: kvaser_usb: Comply with firmware max tx URBs value
  @ 2015-03-16 12:16 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-03-16 12:16 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Andri Yngvason, Linux-CAN, LKML

On Sun, Mar 15, 2015 at 07:08:23PM +0100, Marc Kleine-Budde wrote:
> On 03/15/2015 04:03 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
> > Current driver code arbitrarily assumes a max outstanding tx
> > value of 16 parallel transmissions. Meanwhile, the device
> > firmware provides its actual maximum inside its reply to the
> > CMD_GET_SOFTWARE_INFO message.
> > 
> > Under heavy tx traffic, if the interleaved transmissions count
> > increases above the limit reported by firmware, the firmware
> > breaks up badly, reports a massive list of internal errors, and
> > the candump traces hardly matches the actual frames sent and
> > received.
> > 
> > On the other hand, in certain models, the firmware can support
> > up to 48 tx URBs instead of just 16, increasing the driver
> > throughput by two-fold and reducing the possibility of -ENOBUFs.
> > 
> > Thus dynamically set the driver's max tx URBs value according
> > to firmware replies.
> > 
> > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> 
> > @@ -1928,7 +1940,7 @@ static int kvaser_usb_init_one(struct usb_interface *intf,
> >  		return err;
> >  	}
> >  
> > -	netdev_dbg(netdev, "device registered\n");
> > +	netdev_info(netdev, "device registered\n");
> 
> This makes the driver more noisy, I'd like to drop that hunk, okay? No
> need to resend.
> 

Sure, go ahead.

I have my reasons for that hunk above, but we can always discuss
this in another separate patch ;-)

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 3/3] can: kvaser_usb: Use can-dev unregistration mechanism
  @ 2015-03-14 16:06 99%             ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-03-14 16:06 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Andri Yngvason, Linux-CAN, LKML, netdev

On Sat, Mar 14, 2015 at 04:55:11PM +0100, Marc Kleine-Budde wrote:
> On 03/14/2015 04:41 PM, Ahmed S. Darwish wrote:
> > On Sat, Mar 14, 2015 at 04:26:56PM +0100, Marc Kleine-Budde wrote:
> >> On 03/14/2015 02:11 PM, Ahmed S. Darwish wrote:
> >>> From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> >>>
> >>> Use can-dev's unregister_candev() instead of directly calling
> >>> networking unregister_netdev(). While both are functionally
> >>> equivalent, unregister_candev() might do extra stuff in the
> >>> future than just calling networking layer unregistration code.
> >>
> >> Since 2 goes into can, I've applied this into can-next.
> 
> > Was this a cherry-pick? Because I was going to send a new
> > series with patch #2 better worded, and with a new patch for
> > the endiannes issue.
> 
> Yes, no need to resend patch #3, as it's already applied to can-next.
> 
> regards,
> Marc
> 
> 1 = can: kvaser_usb: Fix tx queue start/stop race conditions
> 2 = can: kvaser_usb: Utilize all possible tx URBs
> 3 = can: kvaser_usb: Use can-dev unregistration mechanism
> 4 = the endianess issue
> 
> 1 = is in linux-can and included in linux-can-fixes-for-4.0-20150314
> 2 = will go into linux-can with a better commit message
>     which is currently prepare by you
>     will be in the next pull request for net
> 3 = is in linux-can-next and will be included in the next pull request
>     for net-next
> 4 = is currently prepared by you
>     will be in the next pull request for net
> 
> This means, you'll send me patches 2 and 4 in a new v5 series. (This
> patches will of course have new numbers, 1 and 2.)
> 

A piece of cake :D

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 3/3] can: kvaser_usb: Use can-dev unregistration mechanism
  @ 2015-03-14 15:41 99%         ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2015-03-14 15:41 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Andri Yngvason, Linux-CAN, LKML, netdev

On Sat, Mar 14, 2015 at 04:26:56PM +0100, Marc Kleine-Budde wrote:
> On 03/14/2015 02:11 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
> > Use can-dev's unregister_candev() instead of directly calling
> > networking unregister_netdev(). While both are functionally
> > equivalent, unregister_candev() might do extra stuff in the
> > future than just calling networking layer unregistration code.
> 
> Since 2 goes into can, I've applied this into can-next.
> 

Merci.

Was this a cherry-pick? Because I was going to send a new
series with patch #2 better worded, and with a new patch for
the endiannes issue.

Regards,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 1/3] can: kvaser_usb: Fix tx queue start/stop race conditions
  @ 2015-03-14 15:19 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-03-14 15:19 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Andri Yngvason, Linux-CAN, LKML, netdev

On Sat, Mar 14, 2015 at 03:58:39PM +0100, Marc Kleine-Budde wrote:
> On 03/14/2015 03:38 PM, Ahmed S. Darwish wrote:
> >> Applied to can. This will go into David's net tree and finally into
> >> net-next. Then I'll apply patches 2+3. Nag me, if I forget about them ;)
> >>
> > 
> > Thanks! :-)
> > 
> > So if I've understood correctly, this patch will go to -rc5 and
> > the rest will go into net-next?
> > 
> > If so, IMHO patch #2 should also go to -rc5. I know it's usually
> > frowned up on to add further patches at this late -rc stage, but
> > here's my logic:
> > 
> > The original driver code just _arbitrarily_ assumed a MAX_TX_URB
> > value of 16 parallel transmissions. This value was chosen, it seems,
> > because the driver was heavily based on esd_usb2.c and the esd code
> > just did so :-(
> > 
> > Meanwhile, in the Kvaser hardware at hand, if I've increased the
> > driver's max parallel transmissions little above the recommended
> > limit reported by firmware, the firmware breaks up badly, reports a
> > massive list of internal errors, and the candump traces becomes
> > sort of an internal mess hardly related to the actual frames sent
> > and received.
> 
> In this particular hardware, what's the limit as reported by the firmware?
> 

48 max oustanding tx, which is quite big in itself it seems.

Other drivers in the tree range between 10 (Peak) and 20 tx (8dev).

> > In my case, I was lucky that the brand we own here (*) had a higher
> > max outstanding transmissions value than 16. But if there is hardware
> 
> Okay - higher.
> 
> > out there with a max oustanding tx support < 16 (#), such hardware
> > will break badly under a heavy transmission load :-(
> 
> I see.
> 
> If you add this motivation to the patch description and let the subject
> reflect that this is a "fix" or safety measure rather than a possible
> performance improvement, no-one will say anything against this patch :D
> 

True; I admit the "fix" part should've been clearer :-)

Will send a better worded commit message then.

Thanks a lot,
Darwish

^ permalink raw reply	[relevance 99%]

* [PATCH v4 3/3] can: kvaser_usb: Use can-dev unregistration mechanism
  @ 2015-03-14 13:11 99%     ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2015-03-14 13:11 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, Andri Yngvason
  Cc: Linux-CAN, LKML, netdev

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Use can-dev's unregister_candev() instead of directly calling
networking unregister_netdev(). While both are functionally
equivalent, unregister_candev() might do extra stuff in the
future than just calling networking layer unregistration code.

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
---
 drivers/net/can/usb/kvaser_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 60eadf5..d44fb1e 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1866,7 +1866,7 @@ static void kvaser_usb_remove_interfaces(struct kvaser_usb *dev)
 		if (!dev->nets[i])
 			continue;
 
-		unregister_netdev(dev->nets[i]->netdev);
+		unregister_candev(dev->nets[i]->netdev);
 	}
 
 	kvaser_usb_unlink_all_urbs(dev);
-- 
1.9.1


^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3 2/3] can: kvaser_usb: Utilize all possible tx URBs
  @ 2015-03-12 10:52 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-03-12 10:52 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Andri Yngvason, Linux-CAN, LKML

On Wed, Mar 11, 2015 at 10:53:28PM +0100, Marc Kleine-Budde wrote:
> On 03/11/2015 06:39 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
> > The driver currently limits the number of outstanding, not yet
> > ACKed, transfers to 16 URBs. Meanwhile, the Kvaser firmware
> > provides its actual max supported number of outstanding
> > transmissions in its reply to the CMD_GET_SOFTWARE_INFO message.
> > 
> > One example is the UsbCan-II HS/LS device which reports support
> > of up to 48 tx URBs instead of just 16, increasing the driver
> > throughput by two-fold and reducing the possibility of -ENOBUFs.
> > 
> > Dynamically set the max tx URBs value according to firmware
> > replies.
> > 
> > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > ---
> >  drivers/net/can/usb/kvaser_usb.c | 55 +++++++++++++++++++++++++++-------------
> >  1 file changed, 37 insertions(+), 18 deletions(-)
> > 
> > changelog-v3: No changes
> > 
> > diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
> > index e97a08c..30b4d47 100644
> > --- a/drivers/net/can/usb/kvaser_usb.c
> > +++ b/drivers/net/can/usb/kvaser_usb.c
> > @@ -25,7 +25,6 @@
> >  #include <linux/can/dev.h>
> >  #include <linux/can/error.h>
> >  
> > -#define MAX_TX_URBS			16
> >  #define MAX_RX_URBS			4
> >  #define START_TIMEOUT			1000 /* msecs */
> >  #define STOP_TIMEOUT			1000 /* msecs */
> > @@ -456,8 +455,13 @@ struct kvaser_usb {
> >  	struct usb_endpoint_descriptor *bulk_in, *bulk_out;
> >  	struct usb_anchor rx_submitted;
> >  
> > +	/* @max_tx_urbs: Firmware-reported maximum number of possible
> > +	 * outstanding transmissions on this specific Kvaser hardware. The
> > +	 * value is also used as a sentinel for marking free URB contexts.
> > +	 */
> >  	u32 fw_version;
> >  	unsigned int nchannels;
> > +	unsigned int max_tx_urbs;
> >  	enum kvaser_usb_family family;
> >  
> >  	bool rxinitdone;
> > @@ -470,7 +474,7 @@ struct kvaser_usb_net_priv {
> >  
> >  	spinlock_t tx_contexts_lock;
> >  	int active_tx_contexts;
> > -	struct kvaser_usb_tx_urb_context tx_contexts[MAX_TX_URBS];
> > +	struct kvaser_usb_tx_urb_context *tx_contexts;
> >  
> >  	struct usb_anchor tx_submitted;
> >  	struct completion start_comp, stop_comp;
> > @@ -657,9 +661,13 @@ static int kvaser_usb_get_software_info(struct kvaser_usb *dev)
> >  	switch (dev->family) {
> >  	case KVASER_LEAF:
> >  		dev->fw_version = le32_to_cpu(msg.u.leaf.softinfo.fw_version);
> > +		dev->max_tx_urbs =
> > +			le16_to_cpu(msg.u.leaf.softinfo.max_outstanding_tx);
> >  		break;
> >  	case KVASER_USBCAN:
> >  		dev->fw_version = le32_to_cpu(msg.u.usbcan.softinfo.fw_version);
> > +		dev->max_tx_urbs =
> > +			le16_to_cpu(msg.u.usbcan.softinfo.max_outstanding_tx);
> >  		break;
> >  	}
> >  
> > @@ -715,7 +723,7 @@ static void kvaser_usb_tx_acknowledge(const struct kvaser_usb *dev,
> >  
> >  	stats = &priv->netdev->stats;
> >  
> > -	context = &priv->tx_contexts[tid % MAX_TX_URBS];
> > +	context = &priv->tx_contexts[tid % dev->max_tx_urbs];
> >  
> >  	/* Sometimes the state change doesn't come after a bus-off event */
> >  	if (priv->can.restart_ms &&
> > @@ -744,7 +752,7 @@ static void kvaser_usb_tx_acknowledge(const struct kvaser_usb *dev,
> >  	spin_lock_irqsave(&priv->tx_contexts_lock, flags);
> >  
> >  	can_get_echo_skb(priv->netdev, context->echo_index);
> > -	context->echo_index = MAX_TX_URBS;
> > +	context->echo_index = dev->max_tx_urbs;
> >  	--priv->active_tx_contexts;
> >  	netif_wake_queue(priv->netdev);
> >  
> > @@ -1512,11 +1520,13 @@ error:
> >  
> >  static void kvaser_usb_reset_tx_urb_contexts(struct kvaser_usb_net_priv *priv)
> >  {
> > -	int i;
> > +	int i, max_tx_urbs;
> > +
> > +	max_tx_urbs = priv->dev->max_tx_urbs;
> >  
> >  	priv->active_tx_contexts = 0;
> > -	for (i = 0; i < MAX_TX_URBS; i++)
> > -		priv->tx_contexts[i].echo_index = MAX_TX_URBS;
> > +	for (i = 0; i < max_tx_urbs; i++)
> > +		priv->tx_contexts[i].echo_index = max_tx_urbs;
> >  }
> >  
> >  /* This method might sleep. Do not call it in the atomic context
> > @@ -1702,14 +1712,14 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
> >  		*msg_tx_can_flags |= MSG_FLAG_REMOTE_FRAME;
> >  
> >  	spin_lock_irqsave(&priv->tx_contexts_lock, flags);
> > -	for (i = 0; i < ARRAY_SIZE(priv->tx_contexts); i++) {
> > -		if (priv->tx_contexts[i].echo_index == MAX_TX_URBS) {
> > +	for (i = 0; i < dev->max_tx_urbs; i++) {
> > +		if (priv->tx_contexts[i].echo_index == dev->max_tx_urbs) {
> >  			context = &priv->tx_contexts[i];
> >  
> >  			context->echo_index = i;
> >  			can_put_echo_skb(skb, netdev, context->echo_index);
> >  			++priv->active_tx_contexts;
> > -			if (priv->active_tx_contexts >= MAX_TX_URBS)
> > +			if (priv->active_tx_contexts >= dev->max_tx_urbs)
> >  				netif_stop_queue(netdev);
> >  
> >  			break;
> > @@ -1743,7 +1753,7 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
> >  		spin_lock_irqsave(&priv->tx_contexts_lock, flags);
> >  
> >  		can_free_echo_skb(netdev, context->echo_index);
> > -		context->echo_index = MAX_TX_URBS;
> > +		context->echo_index = dev->max_tx_urbs;
> >  		--priv->active_tx_contexts;
> >  		netif_wake_queue(netdev);
> >  
> > @@ -1881,7 +1891,7 @@ static int kvaser_usb_init_one(struct usb_interface *intf,
> >  	if (err)
> >  		return err;
> >  
> > -	netdev = alloc_candev(sizeof(*priv), MAX_TX_URBS);
> > +	netdev = alloc_candev(sizeof(*priv), dev->max_tx_urbs);
> >  	if (!netdev) {
> >  		dev_err(&intf->dev, "Cannot alloc candev\n");
> >  		return -ENOMEM;
> > @@ -1889,6 +1899,13 @@ static int kvaser_usb_init_one(struct usb_interface *intf,
> >  
> >  	priv = netdev_priv(netdev);
> >  
> > +	priv->tx_contexts = kzalloc(dev->max_tx_urbs *
> > +				    sizeof(*priv->tx_contexts), GFP_KERNEL);
> > +	if (!priv->tx_contexts) {
> > +		free_candev(netdev);
> > +		return -ENOMEM;
> > +	}
> 
> I'm missing a free for the priv->tx_contexts. I see two options:
> 

Correct. Should not have missed that.

> 1) use devm_kzalloc(), or
> 2) move struct kvaser_usb_tx_urb_context tx_contexts[]; to the end of
>    struct kvaser_usb_net_priv, see [1] for an example.
> 
>    Without further testing, I think the correct alloc for that case
>    would be:
>        alloc_candev(sizeof(*priv + dev->max_tx_urbs *
>                sizeof(struct kvaser_usb_tx_urb_context))
> 

The first option looks better I guess. I'll have to check though
if the resource handling done by devm_kmalloc() will work even
if the probe() method fails with -ENODEV and the like...

> Marc
> 
> [1] http://stackoverflow.com/questions/2060974/dynamic-array-in-struct-c
> 

Thanks for the link. Didn't know that such a "hack" has gained
official status by C99 :-)

Regards,
Darwish

^ permalink raw reply	[relevance 99%]

* [PATCH v3 3/3] can: kvaser_usb: Use can-dev unregistration mechanism
  @ 2015-03-11 17:39 99%     ` Ahmed S. Darwish
    1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-03-11 17:39 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, Andri Yngvason
  Cc: Linux-CAN, LKML

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Use can-dev's unregister_candev() instead of directly calling
networking unregister_netdev(). While both are functionally
equivalent, unregister_candev() might do extra stuff in the
future than just calling networking layer unregistration code.

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
---
 drivers/net/can/usb/kvaser_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 30b4d47..fafcb89 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1866,7 +1866,7 @@ static void kvaser_usb_remove_interfaces(struct kvaser_usb *dev)
 		if (!dev->nets[i])
 			continue;
 
-		unregister_netdev(dev->nets[i]->netdev);
+		unregister_candev(dev->nets[i]->netdev);
 	}
 
 	kvaser_usb_unlink_all_urbs(dev);
-- 
1.9.1


^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 1/3] can: kvaser_usb: Fix tx queue start/stop race conditions
  @ 2015-03-11 15:57 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-03-11 15:57 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Andri Yngvason, Linux-CAN, LKML

On Wed, Mar 11, 2015 at 04:36:52PM +0100, Marc Kleine-Budde wrote:
> On 03/11/2015 04:23 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
> > A number of tx queue wake-up events went missing due to the
> > outlined scenario below. Start state is a pool of 16 tx URBs,
> > active tx_urbs count = 15, with the netdev tx queue open.
> > 
> > start_xmit()                             tx_acknowledge()
> > ............                             ................
> > atomic_inc(&tx_urbs);
> > if (atomic_read(&tx_urbs) >= 16) {
> >                         URB completion IRQ!
> >                         -->
> >                                          atomic_dec(&tx_urbs);
> >                                          netif_wake_queue();
> >                                          return;
> >                         <--
> >                         end of IRQ!
> >     netif_stop_queue();
> > }
> > 
> > At the end, the correct state expected is a 15 tx_urbs count
> > value with the tx queue state _open_. Due to the race, we get
> > the same tx_urbs value but with the tx queue state _stopped_.
> > The wake-up event is completely lost.
> > 
> > Thus avoid hand-rolled concurrency mechanisms and use a proper
> > lock for contexts protection.
> 
> I'm missing a spin_lock_init(), right? Please compile and test your code
> with everything switch on in Kernel hacking -> Lock Debugging.
> 

Ouch... that passed through it seems since __ARCH_SPIN_LOCK_UNLOCKED
is always zero on x86. Recompiling the kernel and re-iterating another
patch series.

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* [PATCH v2 3/3] can: kvaser_usb: Use can-dev unregistration mechanism
  @ 2015-03-11 15:30 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-03-11 15:30 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, Andri Yngvason
  Cc: Linux-CAN, LKML

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Use can-dev's unregister_candev() instead of directly calling
networking unregister_netdev(). While both are functionally
equivalent, unregister_candev() might do extra stuff in the
future than just calling networking layer unregistration code.

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
---
 drivers/net/can/usb/kvaser_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 0742d53..f9c14e8 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1866,7 +1866,7 @@ static void kvaser_usb_remove_interfaces(struct kvaser_usb *dev)
 		if (!dev->nets[i])
 			continue;
 
-		unregister_netdev(dev->nets[i]->netdev);
+		unregister_candev(dev->nets[i]->netdev);
 	}
 
 	kvaser_usb_unlink_all_urbs(dev);
-- 
1.9.1


^ permalink raw reply	[relevance 99%]

* Re: [PATCH 1/5] can: kvaser_usb: Avoid double free on URB submission failures
  @ 2015-03-09 12:32 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-03-09 12:32 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Andri Yngvason, Linux-CAN, LKML

Hi Marc,

(Sorry for the late reply as I was out of town!)

On Wed, Mar 04, 2015 at 10:15:45AM +0100, Marc Kleine-Budde wrote:
> On 02/26/2015 04:20 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
> > Upon a URB submission failure, the driver calls usb_free_urb()
> > but then manually frees the URB buffer by itself.  Meanwhile
> > usb_free_urb() has alredy freed out that transfer buffer since
> > we're the only code path holding a reference to this URB.
> > 
> > Remove two of such invalid manual free().
> > 
> > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> 
> Applied 1+2 and added stable on Cc. Can you please shuffle the remaining
> patches, so that patch 5 comes first, then 4 and 3 as the last patch. As
> 5 is a bugfix it should go into stable, while 3 isn't.
>
> You can base your series on the can/testing branch.
> 

Did not care much about the bugfixes order this time as the patches
themselves will not apply cleanly (or at all) to -stable due to the
addition of UsbCAN-II code, which all -stable kernels do not have.
Thus I guess I'll need to submit a different patch series for -stable
with patches 1, 2, and 5 -- rebased.

Nonetheless, you're correct that having the bugfixes (1,2,5), then the
optimization (4), then the janitorial fix (3) is the logical order for
history & bisection sake. So.. I'll re-order the patches, individually
test with the new order, and re-submit over can/testing.

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* [PATCH 4/5] can: kvaser_usb: Use can-dev unregistration mechanism
  @ 2015-02-26 15:25 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-02-26 15:25 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, Andri Yngvason
  Cc: Linux-CAN, LKML

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Use can-dev's unregister_candev() instead of directly calling
networking unregister_netdev(). While both are functionally
equivalent, unregister_candev() might do extra stuff in the
future than just calling networking layer unregistration code.

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
---
 drivers/net/can/usb/kvaser_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 8f835a1..13bae86 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1844,7 +1844,7 @@ static void kvaser_usb_remove_interfaces(struct kvaser_usb *dev)
 		if (!dev->nets[i])
 			continue;
 
-		unregister_netdev(dev->nets[i]->netdev);
+		unregister_candev(dev->nets[i]->netdev);
 	}
 
 	kvaser_usb_unlink_all_urbs(dev);
-- 
1.9.1


^ permalink raw reply	[relevance 99%]

* [PATCH v6 2/7] can: kvaser_usb: Send correct context to URB completion
  @ 2015-01-26  5:22 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-26  5:22 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, Andri Yngvason
  Cc: Linux-CAN, netdev, LKML

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Send expected argument to the URB completion hander: a CAN
netdevice instead of the network interface private context
`kvaser_usb_net_priv'.

This was discovered by having some garbage in the kernel
log in place of the netdevice names: can0 and can1.

Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
---
 drivers/net/can/usb/kvaser_usb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index 978a25e..f0c6207 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -587,7 +587,7 @@ static int kvaser_usb_simple_msg_async(struct kvaser_usb_net_priv *priv,
 			  usb_sndbulkpipe(dev->udev,
 					  dev->bulk_out->bEndpointAddress),
 			  buf, msg->len,
-			  kvaser_usb_simple_msg_callback, priv);
+			  kvaser_usb_simple_msg_callback, netdev);
 	usb_anchor_urb(urb, &priv->tx_submitted);
 
 	err = usb_submit_urb(urb, GFP_ATOMIC);
-- 
1.7.7.6


^ permalink raw reply	[relevance 99%]

* Re: [PATCH v5 4/5] can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT
  @ 2015-01-25 11:59 99%           ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-25 11:59 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, Andri Yngvason, Linux-CAN, netdev, LKML

On Wed, Jan 21, 2015 at 03:24:46PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 1/21/2015 12:48 AM, Ahmed S. Darwish wrote:
> 
> >From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> 
> >On some x86 laptops, plugging a Kvaser device again after an
> >unplug makes the firmware always ignore the very first command.
> >For such a case, provide some room for retries instead of
> >completly exiting the driver init code.
> 
>    Completely.
> 
> >Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> >---
> >  drivers/net/can/usb/kvaser_usb.c | 12 ++++++++++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> >diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
> >index 640b0eb..068e76c 100644
> >--- a/drivers/net/can/usb/kvaser_usb.c
> >+++ b/drivers/net/can/usb/kvaser_usb.c
> [...]
> >@@ -1632,7 +1632,15 @@ static int kvaser_usb_probe(struct usb_interface *intf,
> >
> >  	usb_set_intfdata(intf, dev);
> >
> >-	err = kvaser_usb_get_software_info(dev);
> >+	/* On some x86 laptops, plugging a Kvaser device again after
> >+	 * an unplug makes the firmware always ignore the very first
> >+	 * command. For such a case, provide some room for retries
> >+	 * instead of completly exiting the driver.
> 
>    Completely.
> 

Thanks, both fixed in the next submission :-D

Regards,
Darwish


^ permalink raw reply	[relevance 99%]

* Re: [PATCH 01/13] kdbus: add documentation
  @ 2015-01-25  3:30 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-25  3:30 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: arnd, ebiederm, gnomes, teg, jkosina, luto, linux-api,
	linux-kernel, daniel, dh.herrmann, tixxdz,
	Michael Kerrisk (man-pages),
	Linus Torvalds, Daniel Mack

On Fri, Jan 23, 2015 at 09:19:46PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 23, 2015 at 08:28:20AM +0200, Ahmed S. Darwish wrote:
> > On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
> > > From: Daniel Mack <daniel@zonque.org>
> > > 
> > > kdbus is a system for low-latency, low-overhead, easy to use
> > > interprocess communication (IPC).
> > > 
> > > The interface to all functions in this driver is implemented via ioctls
> > > on files exposed through a filesystem called 'kdbusfs'. The default
> > > mount point of kdbusfs is /sys/fs/kdbus.
> > 
> > Pardon my ignorance, but we've always been told that adding
> > new ioctl()s to the kernel is a very big no-no.  But given
> > the seniority of the folks stewarding this kdbus effort,
> > there must be a good rationale ;-)
> > 
> > So, can the rationale behind introducing new ioctl()s be
> > further explained? It would be even better if it's included
> > in the documentation patch itself.
> 
> The main reason to use an ioctl is that you want to atomically set
> and/or get something "complex" through the user/kernel boundary.  For
> simple device attributes, sysfs works great, for configuring devices,
> configfs works great, but for data streams / structures / etc. an ioctl
> is the correct thing to use.
> 
> Examples of new ioctls being added to the kernel are all over the
> place, look at all of the special-purpose ioctls the filesystems keep
> creating (they aren't adding new syscalls), look at the monstrosity that
> is the DRM layer, look at other complex things like openvswitch, or
> "simpler" device-specific interfaces like the MEI one, or even more
> complex ones like the MMC interface.  These are all valid uses of ioctls
> as they are device/filesystem specific ways to interact with the kernel.
> 
> The thing is, almost no one pays attention to these new ioctls as they
> are domain-specific interfaces, with open userspace programs talking to
> them, and they work well.  ioctl is a powerful and useful interface, and
> if we were to suddenly require no new ioctls, and require everything to
> be a syscall, we would do nothing except make apis more complex (hint,
> you now have to do extra validation on your file descriptor passed to
> you to determine if it really is what you can properly operate your
> ioctl on), and cause no real benefit at all.
> 
> Yes, people abuse ioctls at times, but really, they are needed.
> 
> And remember, I was one of the people who long ago thought we should not
> be adding more ioctls, but I have seen the folly of my ways, and chalk
> it up to youthful ignorance :)
> 

Exactly, and that's why I wondered about the sudden change
of heart ;-)

Thanks for taking the time to write this.

Regards,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling
  @ 2015-01-25  3:21 99%       ` Ahmed S. Darwish
    1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-25  3:21 UTC (permalink / raw)
  To: Andri Yngvason
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, Linux-CAN, netdev, LKML

Hi!

On Wed, Jan 21, 2015 at 04:20:25PM +0000, Andri Yngvason wrote:
> Quoting Ahmed S. Darwish (2015-01-20 21:45:37)
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
> > Replace most of the can interface's state and error counters
> > handling with the new can-dev can_change_state() mechanism.
> > 
> > Suggested-by: Andri Yngvason <andri.yngvason@marel.com>
> > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > ---
> >  drivers/net/can/usb/kvaser_usb.c | 114 +++++++++++++++++++--------------------
> >  1 file changed, 55 insertions(+), 59 deletions(-)
> > 
> > diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
> > index 971c5f9..0386d3f 100644
> > --- a/drivers/net/can/usb/kvaser_usb.c
> > +++ b/drivers/net/can/usb/kvaser_usb.c
> > @@ -620,40 +620,43 @@ static void kvaser_usb_unlink_tx_urbs(struct kvaser_usb_net_priv *priv)
> >  }
> >  
> >  static void kvaser_usb_rx_error_update_can_state(struct kvaser_usb_net_priv *priv,
> > -                                                const struct kvaser_usb_error_summary *es)
> > +                                                const struct kvaser_usb_error_summary *es,
> > +                                                struct can_frame *cf)
> >  {
> >         struct net_device_stats *stats;
> > -       enum can_state new_state;
> > -
> > -       stats = &priv->netdev->stats;
> > -       new_state = priv->can.state;
> > +       enum can_state cur_state, new_state, tx_state, rx_state;
> >  
> >         netdev_dbg(priv->netdev, "Error status: 0x%02x\n", es->status);
> >  
> > -       if (es->status & M16C_STATE_BUS_OFF) {
> > -               priv->can.can_stats.bus_off++;
> > +       stats = &priv->netdev->stats;
> > +       new_state = cur_state = priv->can.state;
> > +
> > +       if (es->status & M16C_STATE_BUS_OFF)
> >                 new_state = CAN_STATE_BUS_OFF;
> > -       } else if (es->status & M16C_STATE_BUS_PASSIVE) {
> > -               if (priv->can.state != CAN_STATE_ERROR_PASSIVE)
> > -                       priv->can.can_stats.error_passive++;
> > +       else if (es->status & M16C_STATE_BUS_PASSIVE)
> >                 new_state = CAN_STATE_ERROR_PASSIVE;
> > -       }
> >  
> >         if (es->status == M16C_STATE_BUS_ERROR) {
> > -               if ((priv->can.state < CAN_STATE_ERROR_WARNING) &&
> > -                   ((es->txerr >= 96) || (es->rxerr >= 96))) {
> > -                       priv->can.can_stats.error_warning++;
> > +               if ((cur_state < CAN_STATE_ERROR_WARNING) &&
> > +                   ((es->txerr >= 96) || (es->rxerr >= 96)))
> >                         new_state = CAN_STATE_ERROR_WARNING;
> > -               } else if (priv->can.state > CAN_STATE_ERROR_ACTIVE) {
> > +               else if (cur_state > CAN_STATE_ERROR_ACTIVE)
> >                         new_state = CAN_STATE_ERROR_ACTIVE;
> > -               }
> >         }
> >  
> >         if (!es->status)
> >                 new_state = CAN_STATE_ERROR_ACTIVE;
> >  
> > +       if (new_state != cur_state) {
> > +               tx_state = (es->txerr >= es->rxerr) ? new_state : 0;
> > +               rx_state = (es->txerr <= es->rxerr) ? new_state : 0;
> > +
> > +               can_change_state(priv->netdev, cf, tx_state, rx_state);
>
> This (below) is redundant. It doesn't harm but at this point can_change_state
> has set priv->can.state to new_state.
>
> > +               new_state = priv->can.state;
> > +       }
> > +

Correct; I will remove it.

> >         if (priv->can.restart_ms &&
> > -           (priv->can.state >= CAN_STATE_BUS_OFF) &&
> > +           (cur_state >= CAN_STATE_BUS_OFF) &&
> >             (new_state < CAN_STATE_BUS_OFF)) {
> >                 priv->can.can_stats.restarts++;
> >         }
> > @@ -665,18 +668,17 @@ static void kvaser_usb_rx_error_update_can_state(struct kvaser_usb_net_priv *pri
> >  
> >         priv->bec.txerr = es->txerr;
> >         priv->bec.rxerr = es->rxerr;
> > -       priv->can.state = new_state;
> >  }
> >  
> >  static void kvaser_usb_rx_error(const struct kvaser_usb *dev,
> >                                 const struct kvaser_msg *msg)
> >  {
> > -       struct can_frame *cf;
> > +       struct can_frame *cf, tmp_cf = { .can_id = CAN_ERR_FLAG, .can_dlc = CAN_ERR_DLC };
> >         struct sk_buff *skb;
> >         struct net_device_stats *stats;
> >         struct kvaser_usb_net_priv *priv;
> >         struct kvaser_usb_error_summary es = { };
> > -       enum can_state old_state;
> > +       enum can_state old_state, new_state;
> >  
> >         switch (msg->id) {
> >         case CMD_CAN_ERROR_EVENT:
> > @@ -721,60 +723,54 @@ static void kvaser_usb_rx_error(const struct kvaser_usb *dev,
> >         }
> >  
> >         /* Update all of the can interface's state and error counters before
> > -        * trying any skb allocation that can actually fail with -ENOMEM.
> > +        * trying any memory allocation that can actually fail with -ENOMEM.
> > +        *
> > +        * We send a temporary stack-allocated error can frame to
> > +        * can_change_state() for the very same reason.
> > +        *
> > +        * TODO: Split can_change_state() responsibility between updating the
> > +        * can interface's state and counters, and the setting up of can error
> > +        * frame ID and data to userspace. Remove stack allocation afterwards.
> >          */
> >         old_state = priv->can.state;
> > -       kvaser_usb_rx_error_update_can_state(priv, &es);
> > +       kvaser_usb_rx_error_update_can_state(priv, &es, &tmp_cf);
> > +       new_state = priv->can.state;
> >  
> >         skb = alloc_can_err_skb(priv->netdev, &cf);
> >         if (!skb) {
> >                 stats->rx_dropped++;
> >                 return;
> >         }
> > +       memcpy(cf, &tmp_cf, sizeof(*cf));
> >  
> > -       if (es.status & M16C_STATE_BUS_OFF) {
> > -               cf->can_id |= CAN_ERR_BUSOFF;
> > -
> > -               if (!priv->can.restart_ms)
> > -                       kvaser_usb_simple_msg_async(priv, CMD_STOP_CHIP);
> > -               netif_carrier_off(priv->netdev);
> > -       } else if (es.status & M16C_STATE_BUS_PASSIVE) {
> > -               if (old_state != CAN_STATE_ERROR_PASSIVE) {
> > -                       cf->can_id |= CAN_ERR_CRTL;
> > -
> > -                       if (es.txerr || es.rxerr)
> > -                               cf->data[1] = (es.txerr > es.rxerr)
> > -                                               ? CAN_ERR_CRTL_TX_PASSIVE
> > -                                               : CAN_ERR_CRTL_RX_PASSIVE;
> > -                       else
> > -                               cf->data[1] = CAN_ERR_CRTL_TX_PASSIVE |
> > -                                             CAN_ERR_CRTL_RX_PASSIVE;
> > +       if (new_state != old_state) {
> > +               if (es.status & M16C_STATE_BUS_OFF) {
> > +                       if (!priv->can.restart_ms)
> > +                               kvaser_usb_simple_msg_async(priv, CMD_STOP_CHIP);
> > +                       netif_carrier_off(priv->netdev);
> > +               }
> > +
>
> This block [below] is wrong. The usage of PROT_ACTIVE is based on a misunderstanding.
> It's used in some drivers to signify back-to-error-active but its original
> meaning is something completely different, AFAIK.
> This is handled in can_change_state() using a new CTRL message; namely:
> CAN_ERR_CTRL_ACTIVE. The newest version of can-utils is up to date with this.
>
> > +               if (es.status == M16C_STATE_BUS_ERROR) {
> > +                       if ((old_state >= CAN_STATE_ERROR_WARNING) ||
> > +                           (es.txerr < 96 && es.rxerr < 96)) {
> > +                               if (old_state > CAN_STATE_ERROR_ACTIVE) {
> > +                                       cf->can_id |= CAN_ERR_PROT;
> > +                                       cf->data[2] = CAN_ERR_PROT_ACTIVE;
> > +                               }
> > +                       }
> >                 }

So I would just make the new_state equals CAN_STATE_ERROR_ACTIVE,
and then can_change_state() will do the right thing? Excellent!!
This means the entire block above can be removed ;-)

[ On another note, the block's if conditions above are faulty and
  fixed in patch #3. This patch (#2) used can_change_state()
  without changing any of that faulty logic to ease any future
  bisection. ]

> > -       }
> >  
> > -       if (es.status == M16C_STATE_BUS_ERROR) {
> > -               if ((old_state < CAN_STATE_ERROR_WARNING) &&
> > -                   ((es.txerr >= 96) || (es.rxerr >= 96))) {
> > -                       cf->can_id |= CAN_ERR_CRTL;
> > -                       cf->data[1] = (es.txerr > es.rxerr)
> > -                                       ? CAN_ERR_CRTL_TX_WARNING
> > -                                       : CAN_ERR_CRTL_RX_WARNING;
> > -               } else if (old_state > CAN_STATE_ERROR_ACTIVE) {
>
> This is also redundant, and wrong:
>
> > +               if (!es.status) {
> >                         cf->can_id |= CAN_ERR_PROT;
> >                         cf->data[2] = CAN_ERR_PROT_ACTIVE;
> >                 }
> > -       }

As in the above; extra code to be removed, yay! ;-)

> >  
> > -       if (!es.status) {
> > -               cf->can_id |= CAN_ERR_PROT;
> > -               cf->data[2] = CAN_ERR_PROT_ACTIVE;
> > -       }
> > -
> > -       if (priv->can.restart_ms &&
> > -           (old_state >= CAN_STATE_BUS_OFF) &&
> > -           (priv->can.state < CAN_STATE_BUS_OFF)) {
> > -               cf->can_id |= CAN_ERR_RESTARTED;
> > -               netif_carrier_on(priv->netdev);
> > +               if (priv->can.restart_ms &&
> > +                   (old_state >= CAN_STATE_BUS_OFF) &&
> > +                   (new_state < CAN_STATE_BUS_OFF)) {
> > +                       cf->can_id |= CAN_ERR_RESTARTED;
> > +                       netif_carrier_on(priv->netdev);
> > +               }
> >         }
> >  
> >         if (es.error_factor) {
> > -- 
> > 1.9.1
> 
> Looking over the patch again, I've noticed that there
> are a few things that are not quite right.
> 

The state-handlig code has become much simpler since your
reveiw and Kleine-Budde's one. Thanks a lot for all the effort.

Regards,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling
  @ 2015-01-25  2:49 99%           ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-25  2:49 UTC (permalink / raw)
  To: Andri Yngvason
  Cc: Marc Kleine-Budde, Olivier Sobrie, Oliver Hartkopp,
	Wolfgang Grandegger, Linux-CAN, netdev, LKML

On Thu, Jan 22, 2015 at 10:14:47AM +0000, Andri Yngvason wrote:
> Quoting Marc Kleine-Budde (2015-01-21 22:59:23)
> > On 01/21/2015 05:20 PM, Andri Yngvason wrote:
> > > Marc, could you merge the "move bus_off++" patch before you merge this so that I
> > > won't have to incorporate this patch-set into it?
> > 
> > ...included in the lastest pull-request to David. Use
> > tags/linux-can-next-for-3.20-20150121 of the can-next repo as you new base.
> > 
> 
> Thanks!
>

I guess I'll re-base my next submission over this tag too.
Nothing in the new 5 patches is substantial enough to be
included in the current kernel release.

Thanks!
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 01/13] kdbus: add documentation
  @ 2015-01-23  6:28 99%   ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2015-01-23  6:28 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: arnd, ebiederm, gnomes, teg, jkosina, luto, linux-api,
	linux-kernel, daniel, dh.herrmann, tixxdz,
	Michael Kerrisk (man-pages),
	Linus Torvalds, Daniel Mack

On Fri, Jan 16, 2015 at 11:16:05AM -0800, Greg Kroah-Hartman wrote:
> From: Daniel Mack <daniel@zonque.org>
> 
> kdbus is a system for low-latency, low-overhead, easy to use
> interprocess communication (IPC).
> 
> The interface to all functions in this driver is implemented via ioctls
> on files exposed through a filesystem called 'kdbusfs'. The default
> mount point of kdbusfs is /sys/fs/kdbus.

Pardon my ignorance, but we've always been told that adding
new ioctl()s to the kernel is a very big no-no.  But given
the seniority of the folks stewarding this kdbus effort,
there must be a good rationale ;-)

So, can the rationale behind introducing new ioctl()s be
further explained? It would be even better if it's included
in the documentation patch itself.

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 4/4] can: kvaser_usb: Retry first bulk transfer on -ETIMEDOUT
  @ 2015-01-12 13:50 99%                 ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-12 13:50 UTC (permalink / raw)
  To: Olivier Sobrie
  Cc: Marc Kleine-Budde, Oliver Hartkopp, Wolfgang Grandegger,
	Greg Kroah-Hartman, Linux-USB, Linux-CAN, netdev, LKML

On Mon, Jan 12, 2015 at 02:33:30PM +0100, Olivier Sobrie wrote:
> Hello,
> 
> On Mon, Jan 12, 2015 at 05:14:07AM -0500, Ahmed S. Darwish wrote:
> > On Sun, Jan 11, 2015 at 09:51:10PM +0100, Marc Kleine-Budde wrote:
> > > On 01/11/2015 09:45 PM, Ahmed S. Darwish wrote:
> > > > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > > > 
> > > > (This is a draft patch, I'm not sure if this fixes the USB
> > > > bug or only its psymptom. Feedback from the linux-usb folks
> > > > is really appreciated.)
> > > > 
> > > > When plugging the Kvaser USB/CAN dongle the first time, everything
> > > > works as expected and all of the transfers from and to the USB
> > > > device succeeds.
> > > > 
> > > > Meanwhile, after unplugging the device and plugging it again, the
> > > > first bulk transfer _always_ returns an -ETIMEDOUT. The following
> > > > behaviour was observied:
> > > > 
> > > > - Setting higher timeout values for the first bulk transfer never
> > > >   solved the issue.
> > > > 
> > > > - Unloading, then loading, our kvaser_usb module in question
> > > >   __always__ solved the issue.
> > > > 
> > > > - Checking first bulk transfer status, and retry the transfer
> > > >   again in case of an -ETIMEDOUT also __always__ solved the issue.
> > > >   This is what the patch below does.
> > > > 
> > > > - In the testing done so far, this issue appears only on laptops
> > > >   but never on PCs (possibly power related?)
> > > > 
> > > > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > > 
> > > Does this patch apply apply between 3 and 4? If not, please re-arrange
> > > the series. As this is a bug fix, patches 1, 2 and 4 will go via
> > > net/master, 3 will go via net-next/master.
> > > 
> > 
> > Since no one complained earlier, I guess this issue only affects
> > USBCAN devices. That's why I've based it above patch #3: adding
> > USBCAN hardware support.
> > 
> > Nonetheless, it won't do any harm for the current Leaf-only
> > driver. So _if_ this is the correct fix, I will update the commit
> > log, refactor the check into a 'do { } while()' loop, and then
> > base it above the Leaf-only net/master fixes on patch #1, and #2.
> > 
> > Any feedback on the USB side of things?
> 
> Can you take a wireshark capture showing the problem?
> It can maybe help people to figure out what happens.
> 

Yeah, I'm planning on doing something similar.

> What kind of usbcan device do you use?

"Kvaser USBcan II HS/LS"

> Which firmware revision is loaded on the device?
> 

The device reports firmware version 2.9.410.

Interesting. The changelog of their latest firmware states
that it "fixed USB configuration issue during USB attach."
That might be the problem.

I have two devices here. I'll update the firmware only for
one of them and see what happens.

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 3/4] can: kvaser_usb: Add support for the Usbcan-II family
  2015-01-12 12:07 99%           ` Ahmed S. Darwish
@ 2015-01-12 12:36 99%             ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-12 12:36 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

On Mon, Jan 12, 2015 at 07:07:41AM -0500, Ahmed S. Darwish wrote:
> Hi Marc,
> 
> On Mon, Jan 12, 2015 at 12:43:56PM +0100, Marc Kleine-Budde wrote:
> > On 01/11/2015 09:36 PM, Ahmed S. Darwish wrote:
> > > +
> > > +	switch (dev->family) {
> > > +	case KVASER_LEAF:
> > > +		rx_msg = msg->u.leaf.rx_can.msg;
> > > +		break;
> > > +	case KVASER_USBCAN:
> > > +		rx_msg = msg->u.usbcan.rx_can.msg;
> > > +		break;
> > > +	default:
> > > +		dev_err(dev->udev->dev.parent,
> > > +			"Invalid device family (%d)\n", dev->family);
> > >  		return;
> > 
> > should not happen.
> > 
> 
> Yes, but otherwise I get GCC warnings of 'rx_msg' possibly
> being unused. I can add __maybe_unused to rx_msg of course,
> but such annotation may hide possible errors in the future.
> 

Ah, what I meant is using uninitialized_var() to suppress the
GCC warning. But, really, using that macro has a bad history
of hiding errors in the future.

Kindly check http://lwn.net/Articles/529954/ for context.

Another solution might be initializing rx_msg to NULL.

> > > +	switch (dev->family) {
> > > +	case KVASER_LEAF:
> > > +		msg_tx_can_flags = &msg->u.tx_can.leaf.flags;
> > > +		break;
> > > +	case KVASER_USBCAN:
> > > +		msg_tx_can_flags = &msg->u.tx_can.usbcan.flags;
> > > +		break;
> > > +	default:
> > > +		dev_err(dev->udev->dev.parent,
> > > +			"Invalid device family (%d)\n", dev->family);
> > > +		goto releasebuf;
> > should not happen, please remove
> 
> Like the 'rx_msg' case above.
> 
> Thanks,
> Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family
  @ 2015-01-12 12:26 99%               ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-12 12:26 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

On Mon, Jan 12, 2015 at 12:51:49PM +0100, Marc Kleine-Budde wrote:
> On 01/08/2015 04:19 PM, Ahmed S. Darwish wrote:
> 
> [...]
> 
> >>>  MODULE_DEVICE_TABLE(usb, kvaser_usb_table);
> >>> @@ -463,7 +631,18 @@ static int kvaser_usb_get_software_info(struct kvaser_usb *dev)
> >>>  	if (err)
> >>>  		return err;
> >>>  
> >>> -	dev->fw_version = le32_to_cpu(msg.u.softinfo.fw_version);
> >>> +	switch (dev->family) {
> >>> +	case KVASER_LEAF:
> >>> +		dev->fw_version = le32_to_cpu(msg.u.leaf.softinfo.fw_version);
> >>> +		break;
> >>> +	case KVASER_USBCAN:
> >>> +		dev->fw_version = le32_to_cpu(msg.u.usbcan.softinfo.fw_version);
> >>> +		break;
> >>> +	default:
> >>> +		dev_err(dev->udev->dev.parent,
> >>> +			"Invalid device family (%d)\n", dev->family);
> >>> +		return -EINVAL;
> >>
> >> The default case should not happen. I think you can remove it.
> 
> > It's true, it _should_ never happen. But I only add such checks if
> > the follow-up code critically depends on a certain `dev->family`
> > behavior. So it's kind of a defensive check against any possible
> > bug in driver or memory.
> > 
> > What do you think?
> 
> The kernel is full of callback functions, if you have a bit flip there
> you're in trouble anyways. A bug in the driver (or other parts of the
> kernel) might overwrite the memory of dev->family, but if this happens,
> more things will break.
> 

I see. Thanks for the explanation.

Most of them are now removed in latest submission, except two to
avoid GCC warnings of variables that "may be used uninitialized".

Regards,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 3/4] can: kvaser_usb: Add support for the Usbcan-II family
  @ 2015-01-12 12:07 99%           ` Ahmed S. Darwish
  2015-01-12 12:36 99%             ` Ahmed S. Darwish
  0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2015-01-12 12:07 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

Hi Marc,

On Mon, Jan 12, 2015 at 12:43:56PM +0100, Marc Kleine-Budde wrote:
> On 01/11/2015 09:36 PM, Ahmed S. Darwish wrote:
[...]
> > diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
> > index 0eb870b..da47d17 100644
> > --- a/drivers/net/can/usb/kvaser_usb.c
> > +++ b/drivers/net/can/usb/kvaser_usb.c
> > @@ -6,10 +6,12 @@
> >   * Parts of this driver are based on the following:
> >   *  - Kvaser linux leaf driver (version 4.78)
> >   *  - CAN driver for esd CAN-USB/2
> > + *  - Kvaser linux usbcanII driver (version 5.3)
> >   *
> >   * Copyright (C) 2002-2006 KVASER AB, Sweden. All rights reserved.
> >   * Copyright (C) 2010 Matthias Fuchs <matthias.fuchs@esd.eu>, esd gmbh
> >   * Copyright (C) 2012 Olivier Sobrie <olivier@sobrie.be>
> > + * Copyright (C) 2015 Valeo Corporation
> >   */
> >  
> >  #include <linux/completion.h>
> > @@ -21,6 +23,15 @@
> >  #include <linux/can/dev.h>
> >  #include <linux/can/error.h>
> >  
> > +/* Kvaser USB CAN dongles are divided into two major families:
> > + * - Leaf: Based on Renesas M32C, running firmware labeled as 'filo'
> > + * - UsbcanII: Based on Renesas M16C, running firmware labeled as 'helios'
> > + */
> > +enum kvaser_usb_family {
> > +	KVASER_LEAF,
> > +	KVASER_USBCAN,
> > +};
> 
> Nitpick: please move after the #defines
> 

Will do.

[...]
> > @@ -616,53 +810,24 @@ static void kvaser_usb_unlink_tx_urbs(struct kvaser_usb_net_priv *priv)
> >  }
> >  
> >  static void kvaser_usb_rx_error(const struct kvaser_usb *dev,
> > -				const struct kvaser_msg *msg)
> > +				struct kvaser_error_summary *es)
> 
> Can you make "struct kvaser_error_summary *es" const?
> 

Sure.

[...]
> > +/* For USBCAN, report error to userspace iff the channels's errors counter
> > + * has increased, or we're the only channel seeing a bus error state.
> > + */
> > +static void kvaser_usbcan_conditionally_rx_error(const struct kvaser_usb *dev,
> > +						 struct kvaser_error_summary *es)
> 
> const struct kvaser_error_summary *es?
>

Ditto.

[...]
> > +
> > +		/* The USBCAN firmware does not support more than 2 channels.
> 
> Does USBCAN support always 2 channels or are there models with 1
> channels, too. I'd rephrase ..."does support up to 2 channels."
> 

Yup, that will be more accurate.

[...]
> > +
> > +	switch (dev->family) {
> > +	case KVASER_LEAF:
> > +		rx_msg = msg->u.leaf.rx_can.msg;
> > +		break;
> > +	case KVASER_USBCAN:
> > +		rx_msg = msg->u.usbcan.rx_can.msg;
> > +		break;
> > +	default:
> > +		dev_err(dev->udev->dev.parent,
> > +			"Invalid device family (%d)\n", dev->family);
> >  		return;
> 
> should not happen.
> 

Yes, but otherwise I get GCC warnings of 'rx_msg' possibly
being unused. I can add __maybe_unused to rx_msg of course,
but such annotation may hide possible errors in the future.

> > +	switch (dev->family) {
> > +	case KVASER_LEAF:
> > +		msg_tx_can_flags = &msg->u.tx_can.leaf.flags;
> > +		break;
> > +	case KVASER_USBCAN:
> > +		msg_tx_can_flags = &msg->u.tx_can.usbcan.flags;
> > +		break;
> > +	default:
> > +		dev_err(dev->udev->dev.parent,
> > +			"Invalid device family (%d)\n", dev->family);
> > +		goto releasebuf;
> should not happen, please remove

Like the 'rx_msg' case above.

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 3/4] can: kvaser_usb: Add support for the Usbcan-II family
  @ 2015-01-12 11:20 99%         ` Ahmed S. Darwish
      2 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-12 11:20 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde
  Cc: David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

Hi Marc,

On Sun, Jan 11, 2015 at 03:36:12PM -0500, Ahmed S. Darwish wrote:
> From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> 
> CAN to USB interfaces sold by the Swedish manufacturer Kvaser are
> divided into two major families: 'Leaf', and 'UsbcanII'.  From an
> Operating System perspective, the firmware of both families behave
> in a not too drastically different fashion.
> 
> This patch adds support for the UsbcanII family of devices to the
> current Kvaser Leaf-only driver.
> 
> CAN frames sending, receiving, and error handling paths has been
> tested using the dual-channel "Kvaser USBcan II HS/LS" dongle. It
> should also work nicely with other products in the same category.
> 

Please delay applying this to as I've just discovered that
removal of two of the device family checks introduced two
un-necessary GCC warnings.

Will send and updated version soon.

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4 4/4] can: kvaser_usb: Retry first bulk transfer on -ETIMEDOUT
  @ 2015-01-12 10:14 99%             ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2015-01-12 10:14 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Greg Kroah-Hartman, Linux-USB, Linux-CAN, netdev, LKML

On Sun, Jan 11, 2015 at 09:51:10PM +0100, Marc Kleine-Budde wrote:
> On 01/11/2015 09:45 PM, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
> > (This is a draft patch, I'm not sure if this fixes the USB
> > bug or only its psymptom. Feedback from the linux-usb folks
> > is really appreciated.)
> > 
> > When plugging the Kvaser USB/CAN dongle the first time, everything
> > works as expected and all of the transfers from and to the USB
> > device succeeds.
> > 
> > Meanwhile, after unplugging the device and plugging it again, the
> > first bulk transfer _always_ returns an -ETIMEDOUT. The following
> > behaviour was observied:
> > 
> > - Setting higher timeout values for the first bulk transfer never
> >   solved the issue.
> > 
> > - Unloading, then loading, our kvaser_usb module in question
> >   __always__ solved the issue.
> > 
> > - Checking first bulk transfer status, and retry the transfer
> >   again in case of an -ETIMEDOUT also __always__ solved the issue.
> >   This is what the patch below does.
> > 
> > - In the testing done so far, this issue appears only on laptops
> >   but never on PCs (possibly power related?)
> > 
> > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> 
> Does this patch apply apply between 3 and 4? If not, please re-arrange
> the series. As this is a bug fix, patches 1, 2 and 4 will go via
> net/master, 3 will go via net-next/master.
> 

Since no one complained earlier, I guess this issue only affects
USBCAN devices. That's why I've based it above patch #3: adding
USBCAN hardware support.

Nonetheless, it won't do any harm for the current Leaf-only
driver. So _if_ this is the correct fix, I will update the commit
log, refactor the check into a 'do { } while()' loop, and then
base it above the Leaf-only net/master fixes on patch #1, and #2.

Any feedback on the USB side of things?

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* [PATCH v4 2/4] can: kvaser_usb: Update error counters before exiting on OOM
  @ 2015-01-11 20:15 99%     ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2015-01-11 20:15 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde
  Cc: David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

From: Ahmed S. Darwish <ahmed.darwish@valeo.com>

Let the error counters be more accurate in case of Out of
Memory conditions.

Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
---
 drivers/net/can/usb/kvaser_usb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
index c32cd61..0eb870b 100644
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -792,6 +792,9 @@ static void kvaser_usb_rx_can_err(const struct kvaser_usb_net_priv *priv,
 	}
 
 	if (msg->u.rx_can.flag & MSG_FLAG_OVERRUN) {
+		stats->rx_over_errors++;
+		stats->rx_errors++;
+
 		skb = alloc_can_err_skb(priv->netdev, &cf);
 		if (!skb) {
 			stats->rx_dropped++;
@@ -801,9 +804,6 @@ static void kvaser_usb_rx_can_err(const struct kvaser_usb_net_priv *priv,
 		cf->can_id |= CAN_ERR_CRTL;
 		cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
 
-		stats->rx_over_errors++;
-		stats->rx_errors++;
-
 		stats->rx_packets++;
 		stats->rx_bytes += cf->can_dlc;
 		netif_rx(skb);
-- 
1.9.1


^ permalink raw reply	[relevance 99%]

* [PATCH v4 00/04] can: Introduce support for Kvaser USBCAN-II devices
  @ 2015-01-11 20:05 99% ` Ahmed S. Darwish
                       ` (6 subsequent siblings)
  7 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2015-01-11 20:05 UTC (permalink / raw)
  To: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde
  Cc: David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

Hi,

Now since earlier v3 submission patches #1-3 got merged, this
is a new patch series expanding on patch v3 #4: support for
the USBCAN-II family.

A new series is introduced due to the extra additions suggested
by code review, which required being added in their own
self-contained patches.

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family
  @ 2015-01-09  3:06 99%           ` Ahmed S. Darwish
    1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-09  3:06 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

On Thu, Jan 08, 2015 at 12:53:37PM +0100, Marc Kleine-Budde wrote:
> On 01/05/2015 07:31 PM, Ahmed S. Darwish wrote:
> > 

[...]

> > 
> > 		cf->can_id |= CAN_ERR_CRTL;
> > 		cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
> > 
> > 		stats->rx_over_errors++;
> > 		stats->rx_errors++;
> > 
> > 		netif_rx(skb);
> > 
> > 		stats->rx_packets++;
> > 		stats->rx_bytes += cf->can_dlc;
> 
> Another patch would be not to touch cf after netif_rx(), please move the stats handling before calling netif_rx(). Same applies to the kvaser_usb_rx_can_msg() function.
> 

BTW, is it guaranteed from the SocketCAN stack that netif_rx()
will never return NET_RX_DROPPED? Because if no guarantee
exists, I guess below fragment cannot be completely correct?

        stats->rx_packets++;
        stats->rx_bytes += cf->can_dlc;
        netif_rx(skb);

On the other hand, I don't see evan a single CAN driver checking
netif_rx() return value, so maybe such a check is an overkill...

Thanks,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] can: kvaser_usb: Don't free packets when tight on URBs
  @ 2015-01-03 14:34 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2015-01-03 14:34 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, David S. Miller, Paul Gortmaker, Linux-CAN,
	netdev, LKML

On Thu, Jan 01, 2015 at 01:59:13PM -0800, Stephen Hemminger wrote:
> On Tue, 23 Dec 2014 17:46:54 +0200
> "Ahmed S. Darwish" <darwish.07@gmail.com> wrote:
> 
> >  	int ret = NETDEV_TX_OK;
> > +	bool kfree_skb_on_error = true;
> >  
> >  	if (can_dropped_invalid_skb(netdev, skb))
> >  		return NETDEV_TX_OK;
> > @@ -1336,6 +1337,7 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
> >  
> >  	if (!context) {
> >  		netdev_warn(netdev, "cannot find free context\n");
> > +		kfree_skb_on_error = false;
> >  		ret =  NETDEV_TX_BUSY;
> 
> You already have a flag value (ret == NETDEV_TX_BUSY), why
> not use that instead of introducing another variable?

Yes, that variable got implicitly removed in v2 patch 1/4.

Thanks,

--
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] can: kvaser_usb: Add support for the Usbcan-II family
  @ 2014-12-30 15:33 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2014-12-30 15:33 UTC (permalink / raw)
  To: Olivier Sobrie
  Cc: Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde,
	David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

On Sun, Dec 28, 2014 at 10:51:34PM +0100, Olivier Sobrie wrote:
[...]
> > > >  
> > > > +	if (LEAF_PRODUCT_ID(id->idProduct)) {
> > > > +		dev->family = KVASER_LEAF;
> > > > +		dev->max_channels = LEAF_MAX_NET_DEVICES;
> > > > +	} else if (USBCAN_PRODUCT_ID(id->idProduct)) {
> > > > +		dev->family = KVASER_USBCAN;
> > > > +		dev->max_channels = USBCAN_MAX_NET_DEVICES;
> > > > +	} else {
> > > > +		dev_err(&intf->dev, "Product ID (%d) does not belong to any "
> > > > +				    "known Kvaser USB family", id->idProduct);
> > > > +		return -ENODEV;
> > > > +	}
> > > > +
> > > 
> > > Is it really required to keep max_channels in the kvaser_usb structure?
> > > If I looked correctly, you use this variable as a replacement for
> > > MAX_NET_DEVICES in the code and MAX_NET_DEVICES is only used in probe
> > > and disconnect functions. I think it can even be replaced by nchannels
> > > in the disconnect path. So I also think that it don't need to be in the
> > > kvaser_usb structure.
> > > 
> > 
> > hmmm.. given the current state of error arbitration explained
> > above, where I cannot accept a dev->nchannels > 2, I guess we
> > have two options:
> > 
> > a) Remove max_channels, and hardcode the channels count
> > correctness logic as follows:
> > 
> >         dev->nchannels = msg.u.cardinfo.nchannels;
> >         if ((dev->family == USBCAN && dev->nchannels > USBCAN_MAX_NET_DEVICES)
> >             || (dev->family == LEAF && dev->nchannels > LEAF_MAX_NET_DEVICES))
> >                 return -EINVAL
> > 
> > b) Leave max_channels in 'struct kvaser_usb' as is.
> > 
> > I personally prefer the solution at 'b)' but I can do it as
> > in 'a)' if you prefer :-)
> 
> Keeping max_channels in the kvaser_usb structure is useless because it
> is only used in one function that is called in the probe function.
> 
> I would prefer to have:
> 	if (dev->nchannels > MAX_NET_DEVICES)
> 		return -EINVAL
> 
> 	if ((dev->family == USBCAN) &&
> 	    (dev->nchannels > MAX_USBCAN_NET_DEVICES))
> 		return -EINVAL
> 
> You can remove LEAF_MAX_NET_DEVICES which is not used, keep
> MAX_NET_DEVICES equals to 3 and remove the MAX() macro.
> The test specific to the USBCAN family can eventually be moved in the
> kvaser_usb_probe() function.
> 

Quite nice, will do it that way in v3.

Regards,
Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 1/4] can: kvaser_usb: Don't free packets when tight on URBs
  @ 2014-12-25  9:38 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2014-12-25  9:38 UTC (permalink / raw)
  To: Greg KH
  Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
	Marc Kleine-Budde, David S. Miller, Paul Gortmaker, Linux-CAN,
	netdev, Linux-stable, LKML

On Wed, Dec 24, 2014 at 06:50:11PM -0800, Greg KH wrote:
> On Thu, Dec 25, 2014 at 01:56:44AM +0200, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
  > > Flooding the Kvaser CAN to USB dongle with multiple reads and
> > writes in high frequency caused seemingly-random panics in the
> > kernel.
> > 
> > On further inspection, it seems the driver erroneously freed the
> > to-be-transmitted packet upon getting tight on URBs and returning
> > NETDEV_TX_BUSY, leading to invalid memory writes and double frees
> > at a later point in time.
> > 
> > Note:
> > 
> > Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY
> > is a driver bug in and out of itself: it means that our start/stop
> > queue flow control is broken.
> > 
> > This patch only fixes the (buggy) error handling code; the root
> > cause shall be fixed in a later commit.
> > 
> > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > ---
> >  drivers/net/can/usb/kvaser_usb.c | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> >  (Marc, Greg, I believe this should also be added to -stable?)
> 
> 
> <formletter>
> 
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
> 
> </formletter>

<msg-response>

Note taken. Sorry about that ;-)

</msg-response>

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] can: kvaser_usb: Don't free packets when tight on URBs
  @ 2014-12-24 15:52 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2014-12-24 15:52 UTC (permalink / raw)
  To: Olivier Sobrie
  Cc: Oliver Hartkopp, Wolfgang Grandegger, Marc Kleine-Budde,
	David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML

Hi Olivier,

On Wed, Dec 24, 2014 at 01:31:20PM +0100, Olivier Sobrie wrote:
> Hello Ahmed,
> 
> On Tue, Dec 23, 2014 at 05:46:54PM +0200, Ahmed S. Darwish wrote:
> > From: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> > 
> > Flooding the Kvaser CAN to USB dongle with multiple reads and
> > writes in high frequency caused seemingly-random panics in the
> > kernel.
> > 
> > On further inspection, it seems the driver erroneously freed the
> > to-be-transmitted packet upon getting tight on URBs and returning
> > NETDEV_TX_BUSY, leading to invalid memory writes and double frees
> > at a later point in time.
> > 
> > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@valeo.com>
> 
> Thank you for the fix.
> 
> > ---
> >  drivers/net/can/usb/kvaser_usb.c | 8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> >  (Generated over 3.19.0-rc1)
> > 
> > diff --git a/drivers/net/can/usb/kvaser_usb.c b/drivers/net/can/usb/kvaser_usb.c
> > index 541fb7a..34c35d8 100644
> > --- a/drivers/net/can/usb/kvaser_usb.c
> > +++ b/drivers/net/can/usb/kvaser_usb.c
> > @@ -1286,6 +1286,7 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
> >  	struct kvaser_msg *msg;
> >  	int i, err;
> >  	int ret = NETDEV_TX_OK;
> > +	bool kfree_skb_on_error = true;
> >  
> >  	if (can_dropped_invalid_skb(netdev, skb))
> >  		return NETDEV_TX_OK;
> > @@ -1336,6 +1337,7 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
> >  
> >  	if (!context) {
> >  		netdev_warn(netdev, "cannot find free context\n");
> > +		kfree_skb_on_error = false;
> 
> Instead of using an extra variable, you can also set skb to NULL here.
> Or maybe better, you can move the dev_kfree_skb() in the two previous
> tests (in the check of variables urb and buf).
> 

Nice, I'll move dev_kfree_skb() to the two earlier tests then.

Thanks,

P.S. mailer and patch identation; had to manually fix them
before replying (but thanks for the quick review, ofc ;-))

> Thank you,
> 
> Olivier
> 
> >  		ret =  NETDEV_TX_BUSY;
> >  		goto releasebuf;
> >  	}
> > @@ -1364,8 +1366,7 @@ static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
> >  	if (unlikely(err)) {
> >  		can_free_echo_skb(netdev, context->echo_index);
> >  
> > -		skb = NULL; /* set to NULL to avoid double free in
> > -			     * dev_kfree_skb(skb) */
> > +		kfree_skb_on_error = false;
> >  
> >  		atomic_dec(&priv->active_tx_urbs);
> >  		usb_unanchor_urb(urb);
> > @@ -1389,7 +1390,8 @@ releasebuf:
> >  nobufmem:
> >  	usb_free_urb(urb);
> >  nourbmem:
> > -	dev_kfree_skb(skb);
> > +	if (kfree_skb_on_error)
> > +		dev_kfree_skb(skb);
> >  	return ret;
> >  }
> > 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Documentation: log_buf_len accepts [KMG]
  @ 2011-02-07 11:40 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2011-02-07 11:40 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: LKML, linux-doc, Randy Dunlap

On Sun, Feb 06, 2011 at 08:40:02PM -0800, Randy Dunlap wrote:
> 
> Update the "log_buf_len" description to use [KMG] syntax for the
> buffer size.
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> 

This implies an ACK for the original patch?

-- 
Darwish
http://darwish.07.googlepages.com

^ permalink raw reply	[relevance 99%]

* [PATCH -next] Documentation: Explain the [KMG] parameters suffix
@ 2011-02-06 17:45 99% Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2011-02-06 17:45 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: LKML, linux-doc

(Also applicable over 2.6.38-rc3)

The '[KMG]' suffix is commonly described after a number of kernel
parameter values documentation.  Explicitly state its semantics.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 89835a4..3deedce 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -144,6 +144,11 @@ a fixed number of characters. This limit depends on the architecture
 and is between 256 and 4096 characters. It is defined in the file
 ./include/asm/setup.h as COMMAND_LINE_SIZE.
 
+Finally, the [KMG] suffix is commonly described after a number of kernel
+parameter values. These 'K', 'M', and 'G' letters represent the _binary_
+multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
+bytes respectively. Such letter suffixes can also be entirely omitted.
+
 
 	acpi=		[HW,ACPI,X86]
 			Advanced Configuration and Power Interface

regards,

-- 
Darwish
http://darwish.07.googlepages.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH, Bugfix] RAMOOPS: Don't overflow over non-allocated regions
  @ 2010-12-27 21:33 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2010-12-27 21:33 UTC (permalink / raw)
  To: Marco Stornelli
  Cc: LKML, Kyungmin Park, David Woodhouse, Greg KH, Andrew Morton,
	Linus Torvalds

On Sat, Dec 25, 2010 at 12:19:35PM +0100, Marco Stornelli wrote:
> Il 25/12/2010 10:57, Ahmed S. Darwish ha scritto:
> > 
> > Current code mis-calculates the ramoops header size, leading to an
> > overflow over the next record at best, or over a non-allocated region
> > at worst. Fix that calculation.
> > 
> > Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
> > --
> 
> Acked-by: Marco Stornelli <marco.stornelli@gmail.com>
>

Someone to push this to Linus before -rc8? Andrew?

--
Darwish
http://darwish.07.googlepages.com

^ permalink raw reply	[relevance 99%]

* Re: Linux 2.6.37-rc7
  @ 2010-12-22 18:18 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2010-12-22 18:18 UTC (permalink / raw)
  To: Jochen Voss; +Cc: Linus Torvalds, Dave Airlie, Chris Wilson, Jesse Barnes, LKML

Hi,

On Tue, 21 Dec 2010 23:30:30 +0000, Jochen Voss wrote:
> On Tue, Dec 21, 2010 at 11:52:17AM -0800, Linus Torvalds wrote:
> > I'm still nervous about some of the regression reports for intel
> > graphics, so please keep testing and reporting. This is the last -rc
> > before xmas (or whatever your holiday may be), so now you all have a
> > few free days when you have nothing better to do than test out an -rc
> > release, right?
>
> For reference, the regression I reported yesterday
> (message id "20101220140615.GA3035@automatix",
> http://www.spinics.net/lists/kernel/msg1126718.html
> on the web) is still present: -rc7 only shows a blank
> screen on my system, -rc7 with 541cc966 reverted works
> without problems.
>

I can confirm the regression: a completely-blank screen right after the
grub prompt.

Printing kernel output using early_printk() all along ('earlyprintk=
serial,keep') shows that the rest of the kernel internally goes on with
its booting process as usual.

Reverting the mentioned 541cc966 commit solves the problem; the bug is
reproducible in both qemu and real hardware.

regards,

-- 
Darwish
http://darwish.07.googlepages.com

^ permalink raw reply	[relevance 99%]

* Re: SMACK netfilter smacklabel socket match
  @ 2008-10-06 23:05 99%                   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-10-06 23:05 UTC (permalink / raw)
  To: Tilman Baumann; +Cc: Casey Schaufler, Linux-Kernel, linux-security-module

Hi Tilman,

On Mon, Oct 6, 2008 at 2:57 PM, Tilman Baumann
<tilman.baumann@collax.com> wrote:
> If I set /smack/nltype to 'unlabeled' I have effectively shut off the
>  network.
...
> This might work well in trusted networks.
> But Internet is untrusted and needs to work too. At least in the most real
> world scenarios. :)
>
> If i set /smack/nltype to 'unlabled' i don't even get SYN packets out.
> (operation not permitted)
>
> That's probably a bug, but I think the "fix" is to disable the ability to
> set the nltype to anything other than CIPSO at least for the time being.

Check this patch:
http://article.gmane.org/gmane.linux.network/95294/match=

As far as I can remember, it does exactly what you're asking for.
There have been some arguments against it, but at least you can get
the idea and _try_ to discuss/enhance it further.

Regards

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH BUGFIX -v2 -rc4] Smack: Respect 'unlabeled' netlabel mode
  @ 2008-05-31  1:12 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-05-31  1:12 UTC (permalink / raw)
  To: Andrew Morton
  Cc: casey, paul.moore, linux-security-module, linux-kernel, netdev,
	Tetsuo Handa

On Fri, May 30, 2008 at 04:25:00PM -0700, Andrew Morton wrote:
> On Sat, 31 May 2008 02:57:51 +0300
> "Ahmed S. Darwish" <darwish.07@gmail.com> wrote:
> 
> > +		mutex_lock(&smack_ambient_lock);
> > +		nlsp->domain = kstrdup(smack_net_ambient, GFP_ATOMIC);
> > +		mutex_unlock(&smack_ambient_lock);
> 
> no no no no no.  And no.
> 
> GFP_ATOMIC is *unreliable*.  Using it in a "security" feature is a bug
> - if it fails, the feature isn't secure any more.
> 
> Failing to check the kmalloc() return value might be a bug.
> 
> If we _need_ GFP_ATOMIC here then taking a mutex in a cannot-sleep
> context is a bug.
> 
> The patch adds a kmalloc but doesn't add a kfree.  Is it leaky?
> 
> Finally, why is there a need to take a lock around a single store
> instruction?

Possibly the worst three lines written ever. GFP_ATOMIC line
was cut-and-paste forgetting to change it to GFP_KERNEL and the lock
is already useless. 

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] de-semaphorize smackfs
  @ 2008-03-18 12:01 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-03-18 12:01 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Jonathan Corbet, linux-kernel, Casey Schaufler

Hi!,

On Tue, Mar 18, 2008 at 9:35 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Mar 17, 2008 at 05:14:40PM -0600, Jonathan Corbet wrote:
>  > While looking at the generic semaphore patch, I came to wonder what the
>  > remaining semaphore users in the kernel were actually doing.  After a
>  > quick grep for down_interruptible(), smackfs remained at the bottom of
>  > my screen.  It seems like a straightforward mutex case - low-hanging
>  > fruit.  So here's a conversion patch; compile-tested only, but what
>  > could go wrong?
>

I have a feeling that a very nice LWN article is under the way :).

>
>  The lock is kept while returning to userspace and could potentially
>  be release by another process.  This is not allowed for mutexes.
>

Yes, this was an artifact of an old design where different processes
write _sessions_ were not allowed to interleave, thus locking them in
the very beginning (open).

Since now those sessions can be interleaved safely, I'll modify this
issue today to move the locking to each write() call instead.

Thanks Jonathan/Cristoph

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [RFC][PATCH -v2] Smack: Integrate with Audit
  @ 2008-03-12 16:43 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-03-12 16:43 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: casey, Andrew Morton, James Morris, Paul Moore, LKML, LSM-ML,
	Audit-ML, Steve Grubb

On Wed, Mar 12, 2008 at 11:48:17AM -0400, Stephen Smalley wrote:
> 
> On Wed, 2008-03-12 at 08:40 -0700, Casey Schaufler wrote:
> > --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > 
> > > 
> > > On Wed, 2008-03-12 at 04:44 +0200, Ahmed S. Darwish wrote:
> > > > Hi!,
> > > > 
> > > > Setup the new Audit hooks for Smack. The AUDIT_SUBJ_USER and 
> > > > AUDIT_OBJ_USER SELinux flags are recycled to avoid `auditd' 
> > > > userspace modifications. Smack only needs auditing on 
> > > > a subject/object bases, so those flags were enough.
> > > 
> > > Only question I have is whether audit folks are ok with reuse of the
> > > flags in this manner, and whether the _USER flag is best suited for this
> > > purpose if you are going to reuse an existing flag (since Smack label
> > > seems more like a SELinux type than a SELinux user).
> > 
> > To-mate-o toe-maht-o.
> > 
> > There really doesn't seem to be any real reason to create a new
> > flag just because the granularity is different. The choice between
> > _USER and _TYPE (and _ROLE for that matter) is arbitrary from a
> > functional point of view. I say that since Smack has users, but
> > not types or roles, _USER makes the most sense.
> 
> Perhaps I misunderstand, but Smack labels don't represent users (i.e.
> user identity) in any way, so it seemed like a mismatch to use the _USER
> flag there.  Whereas types in SELinux bear some similarity to Smack
> labels - simple unstructured names whose meaning is only defined by the
> policy rules.
> 

I think Casey meant the common use of Smack where a login program
(openssh, bin/login, ..) sets a label for each user that logs in, thus
letting each label effectively representing a user.

In a sense, smack labels share a bit of _USER and _TYPE.

> Regardless, it seems like the audit maintainers ought to weigh in on the
> matter.
> 

Indeed.

Regards,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH -v8 -rc3] Security: Introduce security= boot parameter
  @ 2008-03-06 14:32 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-03-06 14:32 UTC (permalink / raw)
  To: James Morris
  Cc: Chris Wright, Stephen Smalley, Eric Paris, Casey Schaufler,
	Paul Moore, Alexey Dobriyan, Andrew Morton, Linus, LKML, LSM-ML

Hi James,

On Thu, Mar 6, 2008, James Morris <jmorris@namei.org> wrote:
> On Thu, 6 Mar 2008, Ahmed S. Darwish wrote:
>
>  >     Handle Andrew's concerns:
>  >     - Use __init and __initdata in appropriate places.
>  >     - Do not rely upon dummy_ops layout, use C99 initializations.
>  >     - Use DEFINE_SPINLOCK instead of dynamic initialization.
>
>  The spinlock is not needed now, if security_module_enable() can only be
>  called during boot via an initcall.
>

Will do.

Would you mind answering my confusions below so I can do the change
with good understanding ?

I see preempt_disable() before calling security and vfs_caches init,
but what will prevent two processors/cores from executing
security_module_enable() concurrently (thus possibly corrupting
chosen_lsm) ?
security_module_enable() is also now used in __init init_smk_fs().

Or the init path got executed serially ?

Thank you,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH -v5 -mm] LSM: Add security= boot parameter
  @ 2008-03-05 23:06 99%                         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-03-05 23:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: jmorris, sds, casey, bunk, chrisw, eparis, adobriyan,
	linux-kernel, linux-security-module

On Thu, Mar 06, 2008 at 12:56:28AM +0200, Ahmed S. Darwish wrote:
> On Wed, Mar 05, 2008 at 02:29:48PM -0800, Andrew Morton wrote:
> > On Tue, 4 Mar 2008 05:04:07 +0200
> > "Ahmed S. Darwish" <darwish.07@gmail.com> wrote:
> > 
> > Can chosen_lsm[] be __initdata?
> > 
> 
> You're the expert ;), I don't really understand the difference.
> 

After being a good citizen and reading the comments in init.h, I think
yes it should be marked so. even though we use it from init_smk_fs
since init_smk_fs is also marked as __init.

Thank you,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH BUGFIX -rc3] Smack: Don't register smackfs if we're not loaded
  2008-03-05 12:44 99% ` Ahmed S. Darwish
@ 2008-03-05 12:51 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-03-05 12:51 UTC (permalink / raw)
  To: Casey Schaufler
  Cc: Linus Torvalds, Stephen Smalley, James Morris, Eric Paris, LKML

On Wed, Mar 05, 2008 at 02:44:45PM +0200, Ahmed S. Darwish wrote:
> On Tue, Mar 04, 2008 at 09:45:04AM -0800, Casey Schaufler wrote:
> > > From: Linus Torvalds <torvalds@linux-foundation.org>
...
> > > 
> > > What is the oops? Why does it happen?
> ...
> > 
> > One solution would be to tighten the smackfs code so that it
> > handles the uninitialized LSM case properly.
> > 
> 
> IMHO no smackfs code should ever execute if smack isn't loaded.
> 
> This means catching it from the very fist step where it registers
> itself in init_smk_fs instead of doing several if(we're enabled) cases
> in the code path.
> 
> The solution should be a _general_ solution, _not_ a SMACK one cause 
> SELinux sufferes from exactly the same problem.
> 

Not to be misunderstood here, I'm used to writing SMACK in capitals.
I ,ofcourse, don't mean shouting (never will).

Regards,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH BUGFIX -rc3] Smack: Don't register smackfs if we're not loaded
  @ 2008-03-05 12:44 99% ` Ahmed S. Darwish
  2008-03-05 12:51 99%   ` Ahmed S. Darwish
  0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2008-03-05 12:44 UTC (permalink / raw)
  To: Casey Schaufler
  Cc: Linus Torvalds, Stephen Smalley, James Morris, Eric Paris, LKML

On Tue, Mar 04, 2008 at 09:45:04AM -0800, Casey Schaufler wrote:
> ----- Original Message ----
> > From: Linus Torvalds <torvalds@linux-foundation.org>
> > To: Ahmed S. Darwish <darwish.07@gmail.com>
> > Cc: Casey Schaufler <casey@schaufler-ca.com>; LKML <linux-kernel@vger.kernel.org>
> > Sent: Tuesday, March 4, 2008 9:21:19 AM
> > Subject: Re: [PATCH BUGFIX -rc3] Smack: Don't register smackfs if we're not loaded
> > 
> > 
> > 
> > On Tue, 4 Mar 2008, Ahmed S. Darwish wrote:
> > > 
> > > Smackfs initialization without an enabled Smack leads to
> > > an early Oops that renders the system unusable.
> > 
> > I really think this is bogus. Global enables like this are just wrong, and 
> > a sign that something else bad is going on.
> > 
> > What is the oops? Why does it happen?
...
> 
> One solution would be to tighten the smackfs code so that it
> handles the uninitialized LSM case properly.
> 

IMHO no smackfs code should ever execute if smack isn't loaded.

This means catching it from the very fist step where it registers
itself in init_smk_fs instead of doing several if(we're enabled) cases
in the code path.

The solution should be a _general_ solution, _not_ a SMACK one cause 
SELinux sufferes from exactly the same problem.

a.k.a:

LSMs need a scalable way to know if they're enabled that makes 
everyone happy ( especially Linus ;) ).

Regads to all,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation
  @ 2008-03-04 15:11 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-03-04 15:11 UTC (permalink / raw)
  To: Rusty Russell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, LKML, lguest, akpm

On Tue, Mar 04, 2008 at 11:55:10PM +1100, Rusty Russell wrote:
> On Monday 25 February 2008 02:55:15 Ahmed S. Darwish wrote:
> > Hi all,
> >
> > Beginning from commits close to v2.6.25-rc2, running lguest always oopses
> > the host kernel. Oops is at [1].
> 
> OK, whatever the guest does should not break the host.  So your patch can't be
> the whole solution.
> 
> > static void lguest_set_pmd(pmd_t *pmdp, pmd_t pmdval)
> > {
> > 	*pmdp = pmdval;
> > 	lazy_hcall(LHCALL_SET_PMD, __pa(pmdp)&PAGE_MASK,
> > 		   (__pa(pmdp)&(PAGE_SIZE-1))/4, 0);
> > }
> >
> > The first hcall parameter is global pgdir which looks fine. The second
> > parameter is the pmd index in the pgdir which is suspectful.
> >
> > AFAIK, calculating the index of pmd does not need a divisoin over four.
> > Removing the division made lguest work fine again . Patch is at [2].
> 
> Each pmd is 4 bytes long, so the divide by 4 gives the index into the (top
> level) page. ie. a number in the range 0 to 1023.
> 

aha, now it's clear. 

>
> Indeed, here's the correct fix.  Does it work for you?
> 

Yes it does (after removing the unrelated TSC-if-pentium+ checks). 

Thank you

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH 7/9] Audit: internally use the new LSM audit hooks
  @ 2008-03-04  3:31 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-03-04  3:31 UTC (permalink / raw)
  To: Paul Moore
  Cc: Chris Wright, Stephen Smalley, James Morris, Eric Paris,
	Casey Schaufler, David Woodhouse, Andrew Morton, LKML, Audit-ML,
	LSM-ML

On Mon, Mar 03, 2008 at 06:51:41PM -0500, Paul Moore wrote:
> On Saturday 01 March 2008 3:01:11 pm Ahmed S. Darwish wrote:
...
> >
> >  audit.c       |    7 ------
> >  auditfilter.c |   61
> > ++++++++++++++++------------------------------------------ auditsc.c 
> >    |    9 +++-----
> >  3 files changed, 22 insertions(+), 55 deletions(-)
> 
> For some reason some of your patches are not coming through with correct 
> diffstats (notice the lack of a path relative to the kernel base?).  
> Don't worry too much about it as it's not grounds to reject the patch 
> (at least in my mind) but it's worth looking into on your end for the 
> next time you submit patches.
> 

Yes, it's something weird. I've generated all of those diffstats (including
the right ones) in the same way. Luckily the problem is reproduceable,
I'll check the latest upstream diffstat version and see what happens.

> > Andrew, please atomically merge patch #7 and patch #8. Although
> > a system with patch7 and without patch8 will be compiled fine,
> > the SELinux Audit hooks are not set up yet. This means below
> > audit hooks will point to the dummy hooks instead of SELinux
> > ones even if SELinux is enabled.
> >
> > I could not setup the SELinux hooks first cause they have
> > the same name of the old exported SELinux interface with a
> > difference of one parameter.
> 
> In cases like this where you need patches applied atomically to ensure 
> correct operation you can always combine the two patches into one 
> (assuming they are still small enough to be posted, which shouldn't be 
> a problem here).  Small patches are nice and easy to review, but that 
> doesn't mean you have to break everything up if it is awkward.
> 

I'll keep that in mind.

> I've looked over patches #7, #8, and #9 and they look okay to me, but 
> I'm not tagging them 'Reviewed-by' because they go beyond areas of the 
> kernel that I feel comfortable reviewing at this point.  Rest assured 
> there are other on the To/CC line that can help you out (I see James 
> Morris already Ack'd your entire patch set).
> 
> Thanks for all your work on this, it's a nice improvement.
> 

I'm also very thankful for such a nice review and caring explanations!.

Best,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH -v2 -mm] LSM: Add security= boot parameter
  @ 2008-03-02  7:55 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-03-02  7:55 UTC (permalink / raw)
  To: Casey Schaufler
  Cc: Adrian Bunk, Chris Wright, Stephen Smalley, James Morris,
	Eric Paris, Alexey Dobriyan, LKML, LSM-ML, Anrew Morton

On Sat, Mar 01, 2008 at 07:41:04PM -0800, Casey Schaufler wrote:
> 
> --- "Ahmed S. Darwish" <darwish.07@gmail.com> wrote:
> >
...
> > 
> >  
> >  static struct security_operations selinux_ops = {
> > +	.name =				"selinux",
> > +
> >  	.ptrace =			selinux_ptrace,
> >  	.capget =			selinux_capget,
> >  	.capset_check =			selinux_capset_check,
> > @@ -5420,7 +5422,8 @@ static __init int selinux_init(void)
> >  {
> >  	struct task_security_struct *tsec;
> >  
> > -	if (!selinux_enabled) {
> > +	if (!selinux_enabled || !security_module_enable(&selinux_ops)) {
> > +		selinux_enabled = 0;
> >  		printk(KERN_INFO "SELinux:  Disabled at boot.\n");
> 
> How about "SELinux: Not enabled because LSM %s is already enabled.\n"
> 

Looks better. I'll resend the patch once I know the answer of the SMP
point I asked about in the same thread.

Regards,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH -v2 -mm] LSM: Add security= boot parameter
  @ 2008-03-02  7:49 99%     ` Ahmed S. Darwish
      1 sibling, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2008-03-02  7:49 UTC (permalink / raw)
  To: Casey Schaufler
  Cc: Adrian Bunk, Chris Wright, Stephen Smalley, James Morris,
	Eric Paris, Alexey Dobriyan, LKML, LSM-ML, Anrew Morton

On Sun, Mar 02, 2008 at 01:27:08AM +0200, Ahmed S. Darwish wrote:
> Hi!,
> 
... 
> LSM modules must check now if they are allowed to register
> by calling security_module_enable(ops) first. Modify SELinux 
> and SMACK to do so.
> 
...
>  
> +/* Boot-time LSM user choice */
> +static char chosen_lsm[SECURITY_NAME_MAX + 1];
> +static atomic_t security_ops_registered = ATOMIC_INIT(0);
>  
...
> +int security_module_enable(struct security_operations *ops)
> +{
> +	if (!ops || !ops->name)
> +		return 0;
> +
> +	if (!*chosen_lsm && !atomic_read(&security_ops_registered))
> +		return 1;
> +
...
> @@ -90,6 +134,7 @@ int register_security(struct security_operations *ops)
>  		return -EAGAIN;
>  
>  	security_ops = ops;
> +	atomic_inc(&security_ops_registered);
>  

I'm worried about an implementation detail here. Must the LSM
init calls sequence:
asmlinkage void __init start_kernel(void)
{
	preempt_disable();
	...
	security_init();
	...

int __init security_init(void)
{
	...
	do_security_initcalls();
}
static void __init do_security_initcalls(void)
{
	initcall_t *call;
	call = __security_initcall_start;
	while (call < __security_initcall_end) {
		(*call) ();
		call++;
	}
}
be SMP safe ?

In other words, can the two LSMs 'security_initcall()'s 
(i.e. smack_init() and selinux_init()) be executed concurrently ?

If so, this patch won't be safe.
I'll send a modified one once I know the answer.

Thanks everybody,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH -mm 1/4] LSM: Introduce inode_getsecid and ipc_getsecid hooks
  @ 2008-02-27 16:45 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-02-27 16:45 UTC (permalink / raw)
  To: Paul Moore
  Cc: Chris Wright, Stephen Smalley, James Morris, Eric Paris,
	Casey Schaufler, David Woodhouse, linux-security-module, LKML,
	akpm

Hi Paul,

On Wed, Feb 27, 2008 at 11:04:57AM -0500, Paul Moore wrote:
> On Tuesday 26 February 2008 6:24:11 pm Ahmed S. Darwish wrote:
> > Introduce inode_getsecid(inode, secid) and ipc_getsecid(ipcp, secid)
> > LSM hooks.
> >
> > This hooks will be used instead of similar exported SELinux
> > interfaces.
> >
> > Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> > Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
> > ---
> >
> >  include/linux/security.h |   18 ++++++++++++++++++
> >  security/dummy.c         |   12 ++++++++++++
> >  security/security.c      |   12 ++++++++++++
> >  3 files changed, 42 insertions(+)
> >
...
> ...
> 
> > +static inline void security_ipc_getsecid(struct kern_ipc_perm *ipcp,
> > u32 *secid)
> > +{ } 
> 
> Should these both do a  "*secid = 0;"?
> 

Yes, this will also lead to consistency in the interface espcially 
after changing task_getsecid to do the same (in patch #3).

> > diff --git a/security/dummy.c b/security/dummy.c
> > index 6a0056b..c2f4c52 100644
> > --- a/security/dummy.c
> > +++ b/security/dummy.c
> > @@ -422,6 +422,11 @@ static int dummy_inode_listsecurity(struct inode
> > *inode, char *buffer, size_t bu return 0;
> >  }
> >
> > +static void dummy_inode_getsecid(const struct inode *inode, u32
> > *secid)
> > +{ 
> > +	return;
> > +}
> 
> ...
> 
> > +static void dummy_ipc_getsecid(struct kern_ipc_perm *ipcp, u32
> > *secid)
> > +{ 
> > +	return;
> > +}
> 
> Same question.
> 

Both will be changed to *secid = 0 in the comming send. Thanks!

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: 2.6.25-rc3: Reported regressions from 2.6.24
  @ 2008-02-25 18:24 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-02-25 18:24 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: LKML, Andrew Morton, Linus Torvalds, Adrian Bunk, Ingo Molnar

On Mon, Feb 25, 2008 at 02:41:40AM +0100, Rafael J. Wysocki wrote:
> This message contains a list of some regressions from 2.6.24 reported since
> 2.6.25-rc1 was released, for which there are no fixes in the mainline I know
> of.  If any of them have been fixed already, please let me know.
> 
> If you know of any other unresolved regressions from 2.6.24, please let me know
> either and I'll add them to the list.  Also, please let me know if any of the
> entries below are invalid.
> 

There's an lguest Oops reported here:

http://lkml.org/lkml/2008/2/24/136

and a patch in the same report. It's not yet approved by Rusty, but
Ingo thinks it's fine.

Regards,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation
  @ 2008-02-24 16:26 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-02-24 16:26 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Rusty Russell,
	LKML, lguest, akpm, Jeremy Fitzhardinge

On Sun, Feb 24, 2008 at 05:18:14PM +0100, Ingo Molnar wrote:
> 
> * Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> 
> > I am not sure why the division over four existed in the first place. 
> > It seems bogus, maybe the Xen patch just made the problem appear ?
> 
> i think so - nice detective work and nice fix!
> 

Thanks!. Your turn-around time is super, which is so nice too ;).

> I've picked up your patch into x86.git#testing (until Rusty picks it 
> up), you can track it the following way:
> 
>     http://people.redhat.com/mingo/x86.git/README
> 
> it has other lguest fixes as well - could you double-check that 
> x86.git#testing works fine for you as-is? (i've just updated the git 
> tree so it includes your fix as well)
> 

Ofcourse. I'll send you the results by GMT night.

Regards,

-- 

"Better to light a candle, than curse the darkness"

Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Tasklets: Avoid duplicating __tasklet_{,hi_}schedule() code
  @ 2008-02-20 19:39 99%           ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-02-20 19:39 UTC (permalink / raw)
  To: Dmitry Adamushko; +Cc: Ingo Molnar, LKML, Andrew Morton

On Wed, Feb 20, 2008 at 03:20:52PM +0100, Dmitry Adamushko wrote:
> On 20/02/2008, Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> > On Wed, Feb 20, 2008 at 11:41:13AM +0100, Ingo Molnar wrote:
> > >
> > > * Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> > >
> > > > > > -               local_irq_disable();
> > > > > > -               t->next = __get_cpu_var(tasklet_vec).list;
> > > > > > -               __get_cpu_var(tasklet_vec).list = t;
> > > > > > -               __raise_softirq_irqoff(TASKLET_SOFTIRQ);
> > > > > > -               local_irq_enable();
> > > > > > +               /* We were not lucky enough to run, reschedule. */
> > > > > > +               __tasklet_schedule(t);
> > > > >
> > > > > i think there's a subtle difference that you missed: this one does
> > > > > __raise_softirq_irqoff(), while __tasklet_schedule() does a
> > > > > raise_softirq_irqoff(). (note the lack of undescores)
> > > > >
> > > > > the reason is to avoid infinitely self-activating tasklets.
> > > >
> > > > Indeed, thanks a lot for the explanation. (maybe it's time to check
> > > > for new eyeglasses ;)).
> > >
> > > nah, it's rather subtle and the code looked good to me at first but i
> > > remembered that there was some small detail here to watch out for.
> > >
> > > i really dont like tasklets due to their many, arbitrary scheduling
> > > limitations, we should really use the "turn tasklets into kthreads"
> > > patch i posted last year.
> > >
> >
> > While we are at it, there's a small question that is bothering me
> > for a while (and I'm really thankful for help).
> >
> > I keep reading that softirqs (and naturally, tasklets) got executed
> > in interrupt context at the return from hardirq code path.
> >
> > Checking entry_32.S, I find no mentioning of softirqs on the return
> > path (beginning from ret_from_intr: to restore_all: )
> >
> > The only invocation I'm able to find is from local_bh_enable() and
> > from ksoftirqd/n threads (by calling do_softirq()). AFAIK, both
> > invocations occur in a _nont-interrupt_ context (exception context).
> >
> > So, where does the interrupt-context tasklets invocation really
> > occur ?
> 
> Look at irq_exit() in softirq.c.
> 
> The common sequence is ... -> do_IRQ() --> irq_exit() --> invoke_softirq()
> 
> 

Great, this was the last missing block in my understanding of softirqs :).
Thank you.

[btw, your MUA broke the CC list]

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Tasklets: Avoid duplicating __tasklet_{,hi_}schedule() code
  @ 2008-02-20 13:37 99%       ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2008-02-20 13:37 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Andrew Morton, Ingo Molnar, LKML

On Wed, Feb 20, 2008 at 11:41:13AM +0100, Ingo Molnar wrote:
> 
> * Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> 
> > > > -		local_irq_disable();
> > > > -		t->next = __get_cpu_var(tasklet_vec).list;
> > > > -		__get_cpu_var(tasklet_vec).list = t;
> > > > -		__raise_softirq_irqoff(TASKLET_SOFTIRQ);
> > > > -		local_irq_enable();
> > > > +		/* We were not lucky enough to run, reschedule. */
> > > > +		__tasklet_schedule(t);
> > > 
> > > i think there's a subtle difference that you missed: this one does 
> > > __raise_softirq_irqoff(), while __tasklet_schedule() does a 
> > > raise_softirq_irqoff(). (note the lack of undescores)
> > > 
> > > the reason is to avoid infinitely self-activating tasklets.
> > 
> > Indeed, thanks a lot for the explanation. (maybe it's time to check 
> > for new eyeglasses ;)).
> 
> nah, it's rather subtle and the code looked good to me at first but i 
> remembered that there was some small detail here to watch out for.
> 
> i really dont like tasklets due to their many, arbitrary scheduling 
> limitations, we should really use the "turn tasklets into kthreads" 
> patch i posted last year.
> 

While we are at it, there's a small question that is bothering me
for a while (and I'm really thankful for help). 

I keep reading that softirqs (and naturally, tasklets) got executed 
in interrupt context at the return from hardirq code path.

Checking entry_32.S, I find no mentioning of softirqs on the return
path (beginning from ret_from_intr: to restore_all: )

The only invocation I'm able to find is from local_bh_enable() and
from ksoftirqd/n threads (by calling do_softirq()). AFAIK, both 
invocations occur in a _nont-interrupt_ context (exception context).

So, where does the interrupt-context tasklets invocation really 
occur ?

Thanks

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Tasklets: Avoid duplicating __tasklet_{,hi_}schedule() code
  @ 2008-02-19 16:27 99%   ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2008-02-19 16:27 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Andrew Morton, Ingo Molnar, LKML

On Tue, Feb 19, 2008 at 04:52:52PM +0100, Ingo Molnar wrote:
> 
> * Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> 
> > -		local_irq_disable();
> > -		t->next = __get_cpu_var(tasklet_vec).list;
> > -		__get_cpu_var(tasklet_vec).list = t;
> > -		__raise_softirq_irqoff(TASKLET_SOFTIRQ);
> > -		local_irq_enable();
> > +		/* We were not lucky enough to run, reschedule. */
> > +		__tasklet_schedule(t);
> 
> i think there's a subtle difference that you missed: this one does 
> __raise_softirq_irqoff(), while __tasklet_schedule() does a 
> raise_softirq_irqoff(). (note the lack of undescores)
> 
> the reason is to avoid infinitely self-activating tasklets.
> 

Indeed, thanks a lot for the explanation. (maybe it's time to check
for new eyeglasses ;)).

Regards

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* [PATCH] Tasklets: Avoid duplicating __tasklet_{,hi_}schedule() code
@ 2008-02-19 15:37 99% Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2008-02-19 15:37 UTC (permalink / raw)
  To: Andrew Morton, Ingo Molnar; +Cc: LKML

Hi all,

Avoid duplicating __tasklet_schedule() and __tasklet_hi_schedule()
code in tasklet_action() and tasklet_hi_action() respectively.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---

This also saves a few bytes of image space:

   text	   data	    bss	    dec	    hex	filename
   3632	     12	    324	   3968	    f80	softirq.o.before
   3552	     12	    324	   3888	    f30	softirq.o.after

diff --git a/kernel/softirq.c b/kernel/softirq.c
index 5b3aea5..3068dc3 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -414,11 +414,8 @@ static void tasklet_action(struct softirq_action *a)
 			tasklet_unlock(t);
 		}
 
-		local_irq_disable();
-		t->next = __get_cpu_var(tasklet_vec).list;
-		__get_cpu_var(tasklet_vec).list = t;
-		__raise_softirq_irqoff(TASKLET_SOFTIRQ);
-		local_irq_enable();
+		/* We were not lucky enough to run, reschedule. */
+		__tasklet_schedule(t);
 	}
 }
 
@@ -447,11 +444,8 @@ static void tasklet_hi_action(struct softirq_action *a)
 			tasklet_unlock(t);
 		}
 
-		local_irq_disable();
-		t->next = __get_cpu_var(tasklet_hi_vec).list;
-		__get_cpu_var(tasklet_hi_vec).list = t;
-		__raise_softirq_irqoff(HI_SOFTIRQ);
-		local_irq_enable();
+		/* We were not lucky enough to run, reschedule. */
+		__tasklet_hi_schedule(t);
 	}
 }
 

Regards,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: Linux i386 clone(): %ebx 'frobbing' ?
  @ 2008-02-15 23:54 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-02-15 23:54 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: libc-alpha, libc-alpha, linux-kernel

On Sat, Feb 16, 2008 at 12:28:11AM +0100, Andreas Schwab wrote:
> "Ahmed S. Darwish" <darwish.07@gmail.com> writes:
> 
> > Hi Andreas,
> >
> > On Fri, Feb 15, 2008, Andreas Schwab wrote:
> >> "Ahmed S. Darwish" <darwish.07@gmail.com> writes:
> >> 
> >> > I don't understand how the `fn' argument reached the child thread
> >> > in the %ebx register. It's said in the comment that `fn' will be
> >> > popped to child 'in the ebx frobbing below'. But what does that mean ?
> >> 
> >> See "popl %ebx" after "int $0x80".
> >> 
> >
> > I hope I'm not misreading something obvious, but I can't find
> > the code where FUNC(%esp) is stored in %ebx before %ebx value
> > got pushed in the stack (and restored in above 'popl' statement).
> 
> It is stored in the new stack for the child, as explained in the
> comment.  The parent has a different stack.
> 

Ooh great, I got it. Sorry, my mind didn't connect the dots though 
I read the comment several times. Thanks a lot for bearing with me :).

Regards,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* Re: Linux i386 clone(): %ebx 'frobbing' ?
  @ 2008-02-15 23:07 99%   ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2008-02-15 23:07 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: libc-alpha, libc-alpha, linux-kernel

Hi Andreas,

On Fri, Feb 15, 2008, Andreas Schwab wrote:
> "Ahmed S. Darwish" <darwish.07@gmail.com> writes:
> 
> > I don't understand how the `fn' argument reached the child thread
> > in the %ebx register. It's said in the comment that `fn' will be
> > popped to child 'in the ebx frobbing below'. But what does that mean ?
> 
> See "popl %ebx" after "int $0x80".
> 

I hope I'm not misreading something obvious, but I can't find
the code where FUNC(%esp) is stored in %ebx before %ebx value
got pushed in the stack (and restored in above 'popl' statement).

Thanks a lot for help.

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com


^ permalink raw reply	[relevance 99%]

* [PATCH] lguest: Accept guest _PAGE_PWT page table entries
  @ 2008-02-07  0:51 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2008-02-07  0:51 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rusty Russel, Suresh Siddha, Thomas Gleixner, lguest, linux-kernel

On Thu, Feb 07, 2008 at 12:59:23AM +0100, Ingo Molnar wrote:
> 
> * Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> 
> > Hi all,
> > 
> > Beginning from commit 4138cc3418f5, ioremap_nocache() sets the _PAGE_PWT
> > flag. 
> > 
> > Lguest doesn't accept a guest pte with a _PWT flag and reports a "bad 
> > page table entry" in that case.
> > 
> > I've removed check from lguest code and everything worked fine. Is 
> > this safe from the Lguest side ?
> 
> yes, should be safe. Could you send a patch so that others can apply it 
> too?
> 

Ofcourse :) :

Accept guest _PAGE_PWT page table entries, otherwise lguest will
always fail with a "bad page table entry" message.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---

diff --git a/drivers/lguest/page_tables.c b/drivers/lguest/page_tables.c
index 74b4cf2..952160b 100644
--- a/drivers/lguest/page_tables.c
+++ b/drivers/lguest/page_tables.c
@@ -178,8 +178,8 @@ static void release_pte(pte_t pte)
 
 static void check_gpte(struct lg_cpu *cpu, pte_t gpte)
 {
-	if ((pte_flags(gpte) & (_PAGE_PWT|_PAGE_PSE))
-	    || pte_pfn(gpte) >= cpu->lg->pfn_limit)
+	if ((pte_flags(gpte) & _PAGE_PSE) || 
+	    pte_pfn(gpte) >= cpu->lg->pfn_limit)
 		kill_guest(cpu, "bad page table entry");
 }
 

Regards,

--
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser(2)
  @ 2007-11-11 18:37 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-11-11 18:37 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Casey Schaufler, akpm, torvalds, linux-security-module,
	linux-kernel, Al Viro

Hi Pavel,

On Nov 11, 2007 2:44 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > > A Smack Rule in an "egrep" format is:
> > >
> > > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n"
>
> Perhaps you should make it space, not 'space or tab', and only allow
> lowercase permissions? That way, parser will be slightly simpler, and
> you'll still have a chance to use 'R' as 'slightly different r'.
>

Thanks for your care about this. It seems not a lot of people have
noticed, but to stop any objections not related to the core smack
code, Casey decided to let the parsing be done in a user-space utility
that sends the rules to the kernel in a predefined strict format.

You can find how the whole story in the smackv11 announcement here:
http://article.gmane.org/gmane.linux.kernel.lsm/4463

Regards,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser(2)
  @ 2007-11-10 19:45 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-11-10 19:45 UTC (permalink / raw)
  To: Jakob Oestergaard
  Cc: Casey Schaufler, akpm, torvalds, linux-security-module,
	linux-kernel, Al Viro

On Nov 10, 2007 7:05 PM, Jakob Oestergaard <jakob@unthought.net> wrote:
> ...
> > I've double-checked the code for any possible off-by-one/overflow
> > errors.
> ...
>
> Two things caught my eye.
>
> ...
> > +             case bol:
> > +             case subject:
> > +                     if (*label_len >= SMK_MAXLEN)
> > +                             goto out;
> > +                     subjectstr[(*label_len)++] = data[i];
>
> Why is the '>' necessary?  Could it happen that you had incremented past the
> point of equality?
>
> If that could not happen, then in my oppinion '>=' is very misleading when '=='
> is really what is needed.
>

Indeed, you're absolutely right.

> ...
> > +             case object:
> > +                     if (*prevstate == blank) {
> > +                             subjectstr[*label_len] = '\0';
> > +                             *label_len = 0;
> > +                     }
>
> I wonder why it is valid to uncritically use the already incremented label_len
> here, without checking its value (like is done above).
>
> It seems strangely asymmetrical. I'm not saying it's wrong, because there may
> be a subtle reason as to why it's not, but if that's the case then I think that
> subtle reason should be documented with a comment.
>

Maximum value label_len could reach is "SMK_MAXLEN". The subjectstr
and objectstr arrays are of "SMK_MAXLEN + 1" length. So I think no
danger is here.

Yes, this deserved a comment.

> ...
> > +             case access:
> > +                     if (*prevstate == blank) {
> > +                             objectstr[*label_len] = '\0';
> > +                             *label_len = 0;
> > +                     }
>
> Same applies here.
>
>  / jakob
>

Good spots, thanks a lot for the review.

Regards,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
  @ 2007-11-06 14:30 99%                       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-11-06 14:30 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Kyle Moffett, Casey Schaufler, akpm, torvalds,
	linux-security-module, linux-kernel

On 11/6/07, Adrian Bunk <bunk@kernel.org> wrote:
> On Tue, Nov 06, 2007 at 04:05:13PM +0200, Ahmed S. Darwish wrote:
> >
> > Great, To summarize the discussion. Will there be a problem in
> > accepting ASCII and the UTF-8 ASCII _subset_ _only_ and  return
> > -EINVAL for all other cases/ecnodings ?.
>
> The UTF-8 ASCII subset is the complete ASCII.
>
> > i.e. The fragment I sent in a previous message:
> >
> > /* Filter UTF-8 non-ascii compatible bytes (> 0x7F) */
> > if (!isascii(c)) return -EINVAL;
> > /* Filter unwanted ascii chars */
> > if (!isspace(c) && !isgraph(c)) return -EINVAL;
> >...
>
> As I already said, this should work fine.
>

I thought you were objecting not handling the remaining non-ASCII
UTF-8 bytes. Everything is clear now. A Big thank you to everybody in
this thread for your effort on this :).

Regards,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
  @ 2007-11-06 14:05 99%                   ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-11-06 14:05 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Kyle Moffett, Casey Schaufler, akpm, torvalds,
	linux-security-module, linux-kernel

On Tue, Nov 06, 2007 at 02:34:46PM +0100, Adrian Bunk wrote:
> On Tue, Nov 06, 2007 at 07:49:26AM -0500, Kyle Moffett wrote:
> > On Nov 06, 2007, at 07:23:36, Ahmed S. Darwish wrote:
> >> On 11/6/07, Adrian Bunk <bunk@kernel.org> wrote:
> >>> On Tue, Nov 06, 2007 at 01:34:05PM +0200, Ahmed S. Darwish wrote:
> >>>> As far as I understand the problem now, isspace() accepts the 0xa0 
> >>>> character which might collide with some of UTF-8 encoded characters 
> >>>> cause the high bit is set.
> >>
> >> I admit I'm not experienced in such encoding stuff, but shouldn't the 
> >> ASCII and the ASCII-compatible UTF-8 encodings be enough for the labels?
> >>
> >>> It would not work if someone would e.g. give you UTF-16 encoded strings, 
> >>> but I don't see this happening in practice.
> >>
> >> Won't this complicate the code too much ?
> >
> > Well the VFS (for example) certainly doesn't support any encodings other 
> > than various extended-ASCII forms (which includes UTF-8).  Something like 
> > UTF-16 has extra null characters in-between every normal character, and as 
> > such would fail completely if passed to the VFS.
> 
> Good point.
> 
> > Personally I think that isspace() accepting character 0xA0 is a bug, as 
> > there are several variants of extended ASCII only one of which has that 
> > character as a space.  Others have it as ?? (accented A), etc.
> 
> But even then Smack would still have a similar problem with isgraph().
> 

Great, To summarize the discussion. Will there be a problem in 
accepting ASCII and the UTF-8 ASCII _subset_ _only_ and  return 
-EINVAL for all other cases/ecnodings ?.

i.e. The fragment I sent in a previous message:

/* Filter UTF-8 non-ascii compatible bytes (> 0x7F) */
if (!isascii(c)) return -EINVAL; 
/* Filter unwanted ascii chars */
if (!isspace(c) && !isgraph(c)) return -EINVAL; 

> > In addition 
> > the "canonical" internal text format of the kernel is UTF-8 as that 
> > encoding can represent any character in any other encoding and it is 
> > backwards-compatible with traditional ASCII.
> > 
> > Cheers,
> > Kyle Moffett-
> 
> cu
> Adrian
> 

--
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
  @ 2007-11-06 12:23 99%             ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-11-06 12:23 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Kyle Moffett, Casey Schaufler, akpm, torvalds,
	linux-security-module, linux-kernel

On 11/6/07, Adrian Bunk <bunk@kernel.org> wrote:
> On Tue, Nov 06, 2007 at 01:34:05PM +0200, Ahmed S. Darwish wrote:
> > Hi,
> >
> > On Tue, Nov 06, 2007 at 09:56:51AM +0100, Adrian Bunk wrote:
> > > On Tue, Nov 06, 2007 at 03:26:12AM -0500, Kyle Moffett wrote:
> > > > On Nov 06, 2007, at 01:33:05, Adrian Bunk wrote:
> > > >> Can you limit this to 7bit ASCII and use isascii() somewhere?
> > > >>
> > > >> Otherwise I'd expect funny things to happen when you e.g. use isspace() on
> > > >> the UTF-8 encoded character ??.
> > > >
> > > > Actually, you don't need to.  You tell them it expects UTF-8 encoded
> > > > strings and be done with it.  All US-ASCII characters from 0 through 127
> > > > (IE: high bit clear) are exactly the same in UTF-8, and UTF-8 special
> > > > characters have the high bit set in all bytes.  Therefore you just assume
> > > > that anything with the high bit set is part of a word and you can handle
> > > > basic UTF-8.  (It doesn't work on special UTF-8 space characters like
> > > > nonbreaking space and similar, but handling those is significantly more
> > > > complicated).
> > >
> > > The documentations says:
> > > "Smack labels cannot contain unprintable characters or the "/" (slash)
> > >  character."
> > >
> > > What you propose might contain unprintable characters, and it might even
> > > be invalid UTF-8.
> >
> > As far as I understand the problem now, isspace() accepts the 0xa0
> > character which might collide with some of UTF-8 encoded characters
> > cause the high bit is set.
> >
> > I used "if (!isspace(c) && !isgraph(c)) return -EINVAL;" to test
> > rules' characters validity which seems not enough. I'll add !isascii(c)
> > in the condition and ask Casey to change the documentation to be
> > something like:
> >
> > Smack labels are represented in ASCII characters, they cannot contain
> > unprintable characters or the '/' (slash) character.
> >
> > and in write():
> > if (!isascii(c) return -EINVAL;
> > if (!isspace(c) && !isgraph(c)) return -EINVAL;
> >
> > This satisfy above customized labels rule, right ?
>
> It should work for all charsets you'll usually have to handle.
>

I admit I'm not experienced in such encoding stuff, but shouldn't the
ASCII and the ASCII-compatible UTF-8 encodings be enough for the
labels ?

> It would not work if someone would e.g. give you UTF-16 encoded strings,
> but I don't see this happening in practice.

Won't this complicate the code too much ?

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
  @ 2007-11-06 11:34 99%         ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-11-06 11:34 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Kyle Moffett, Casey Schaufler, akpm, torvalds,
	linux-security-module, linux-kernel

Hi,

On Tue, Nov 06, 2007 at 09:56:51AM +0100, Adrian Bunk wrote:
> On Tue, Nov 06, 2007 at 03:26:12AM -0500, Kyle Moffett wrote:
> > On Nov 06, 2007, at 01:33:05, Adrian Bunk wrote:
> >> Can you limit this to 7bit ASCII and use isascii() somewhere?
> >>
> >> Otherwise I'd expect funny things to happen when you e.g. use isspace() on 
> >> the UTF-8 encoded character ??.
> >
> > Actually, you don't need to.  You tell them it expects UTF-8 encoded 
> > strings and be done with it.  All US-ASCII characters from 0 through 127 
> > (IE: high bit clear) are exactly the same in UTF-8, and UTF-8 special 
> > characters have the high bit set in all bytes.  Therefore you just assume 
> > that anything with the high bit set is part of a word and you can handle 
> > basic UTF-8.  (It doesn't work on special UTF-8 space characters like 
> > nonbreaking space and similar, but handling those is significantly more 
> > complicated).
> 
> The documentations says:
> "Smack labels cannot contain unprintable characters or the "/" (slash) 
>  character."
> 
> What you propose might contain unprintable characters, and it might even 
> be invalid UTF-8.
> 

As far as I understand the problem now, isspace() accepts the 0xa0
character which might collide with some of UTF-8 encoded characters
cause the high bit is set.

I used "if (!isspace(c) && !isgraph(c)) return -EINVAL;" to test 
rules' characters validity which seems not enough. I'll add !isascii(c)
in the condition and ask Casey to change the documentation to be
something like:

Smack labels are represented in ASCII characters, they cannot contain
unprintable characters or the '/' (slash) character.

and in write():
if (!isascii(c) return -EINVAL;
if (!isspace(c) && !isgraph(c)) return -EINVAL;

This satisfy above customized labels rule, right ?

Regards,

--
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
  @ 2007-11-05 23:38 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-11-05 23:38 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Pavel Machek, Casey Schaufler, akpm, linux-security-module,
	linux-kernel, Al Viro

On 11/5/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 5 Nov 2007, Ahmed S. Darwish wrote:
>
> > On Sun, Nov 04, 2007 at 12:28:48PM +0000, Pavel Machek wrote:
> > >
> > > Can we avoid string parsers in the kernel?
> > >
> >
> > Ok, Could someone suggest a better idea please ?.
>
> I personally think string parsers are *much* better than the alternatives
> (which basically boil down to nasty binary interfaces)
>
> > I thought about packing the rules in a structure and sending
> > it over an ioctl() command. Is this applicable ?
>
> That's *MUCH* worse.
>
> Strings are nice. They aren't that complex, and as long as it's not a
> performance-critical area, there are basically no downsides.
>
> Binary structures and ioctl's are *much* worse. They are totally
> undebuggable with generic tools (think "echo" or "strace"), and they are a
> total nightmare to parse across architectures and pointer sizes.
>
> So the rule should be: always use strings if at all possible and relevant.
> If the data is fundamentally binary, it shouldn't be re-coded to ascii (no
> real advantage), but if the data is "stringish", and there aren't big
> performance issues, then keep it as strings.
>

Thanks a lot for such a kind advice. I'll keep that in my mind.

Regards,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
  @ 2007-11-05  9:41 99%     ` Ahmed S. Darwish
    2007-11-04 13:23 99%     ` Ahmed S. Darwish
  1 sibling, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-11-05  9:41 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Casey Schaufler, akpm, torvalds, linux-security-module,
	linux-kernel, Al Viro

On Sun, Nov 04, 2007 at 12:28:48PM +0000, Pavel Machek wrote:
> Hi!
> 
> > > Still to come:
> > > 
> > >   - Final cleanup of smack_load_write and smack_cipso_write.
> > 
> > Hi All,
> > 
> > After agreeing with Casey on the "load" input grammar yesterday, here's
> > the final grammar and its parser (which needs more testing):
> > 
> > A Smack Rule in an "egrep" format is:
> > 
> > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n"
> > 
> > where Subject/Object strings are in the form:
> > 
> > "^[^/[:space:][:cntrl:]]{1,SMK_MAXLEN}$"
> 
> Can we avoid string parsers in the kernel?
> 

Ok, Could someone suggest a better idea please ?. 

I thought about packing the rules in a structure and sending
it over an ioctl() command. Is this applicable ?

> 
> > +static inline int isblank(char c)
> > +{
> > +	return (c == ' ' || c == '\t');
> > +}
> 
> This sounds like enough for 'NAK'.
> 
> 						Pavel,
> 		who still thinks smack rules should be parsed
> 		in userspace and compiled into selinux rules...
> 		
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
  @ 2007-11-04 20:06 99%   ` Ahmed S. Darwish
                       ` (3 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-11-04 20:06 UTC (permalink / raw)
  To: Casey Schaufler; +Cc: akpm, torvalds, linux-security-module, linux-kernel

On 11/3/07, Ahmed S. Darwish <darwish.07@gmail.com> wrote:
>  static int smk_open_load(struct inode *inode, struct file *file)
>  {
> -       return seq_open(file, &load_seq_ops);
> +       if ((file->f_flags & O_ACCMODE) == O_RDONLY)
> +               return seq_open(file, &load_seq_ops);
> +
> +       if (down_interruptible(&smack_write_sem))
> +               return -ERESTARTSYS;
> +
> +       load_state = kzalloc(sizeof(struct smack_load_state), GFP_KERNEL);
> +       if (!load_state)
> +               return -ENOMEM;
> +
> +       return 0;
> +}

Is it right to do the kzalloc with the semaphore being held? Will the
lock be held forever If kzalloc failed and -ENOMEM was returned ?

Thanks,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
    2007-11-05  9:41 99%     ` Ahmed S. Darwish
@ 2007-11-04 13:23 99%     ` Ahmed S. Darwish
  1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-11-04 13:23 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Casey Schaufler, akpm, torvalds, linux-security-module, linux-kernel

On 11/4/07, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > > Still to come:
> > >
> > >   - Final cleanup of smack_load_write and smack_cipso_write.
> >
> > Hi All,
> >
> > After agreeing with Casey on the "load" input grammar yesterday, here's
> > the final grammar and its parser (which needs more testing):
> >
> > A Smack Rule in an "egrep" format is:
> >
> > "^[:space:]*Subject[:space:]+Object[:space:]+[rwxaRWXA-]+[:space:]*\n"
> >
> > where Subject/Object strings are in the form:
> >
> > "^[^/[:space:][:cntrl:]]{1,SMK_MAXLEN}$"
>
> Can we avoid string parsers in the kernel?
>

I've suggested that at first, but (hoping not to misquote Al) Al viro
said that the parsing is simple enough and no need exists for a
user-space utility.

>
> > +static inline int isblank(char c)
> > +{
> > +     return (c == ' ' || c == '\t');
> > +}
>
> This sounds like enough for 'NAK'.
>

Would you please show the reason for the NAK so I can modify the code ?

Thank you,

>                                                 Pavel,
>                 who still thinks smack rules should be parsed
>                 in userspace and compiled into selinux rules...
>

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv10: Smack rules grammar + their stateful parser
  @ 2007-11-03 22:12 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-11-03 22:12 UTC (permalink / raw)
  To: Kyle Moffett
  Cc: Casey Schaufler, akpm, torvalds, linux-security-module, linux-kernel

On 11/3/07, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> On Nov 03, 2007, at 12:43:06, Ahmed S. Darwish wrote:
> > Bashv3 builtin "echo" behaves very strangely to -EINVAL. It sends
> > all the buffers that causes -EINVAL again in subsequent echo
> > invocations.
> >
> > i.e.
> > echo "Invalid Rule" > /smack/load  # -EINVAL returned
> > echo "Valid Rule" > /smack/load
> >
> > In seconod iteration, echo sends the first invalid buffer again
> > then sends the new one. This causes a "Invalid Rule\nValid Rule"
> > buffer sent to write().
> >
> > IMHO, this is a bug in builtin echo. The external /bin/echo doesn't
> > cause such strange behaviour.
>
> Actually, what causes problems here is something between a bug and a
> feature in libc's buffering.  Basically the -EINVAL error causes libc
> to leave its data in the file-output buffer despite the file being
> closed and reopened. Since a standalone echo just exits that buffer
> is discarded, but for the bash builtin it hangs around in the buffer
> for a while and ends up getting prepended to the following echo
> statement.  There's actually multiple ways to make this fail; this is
> just the simplest.
>

Thanks a lot for such a useful info. Is there a way from my side  to
make subsequent echo invocations not affected by previous failed ones
?

Regards,

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Smackv9: Use a stateful parser for parsing Smack rules
  @ 2007-11-02 18:50 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-11-02 18:50 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: casey, akpm, torvalds, linux-security-module, linux-kernel, viro

On 11/1/07, Jan Engelhardt <jengelh@computergmbh.de> wrote:
>
> On Nov 1 2007 17:54, Ahmed S. Darwish wrote:
> >+
> >+static inline int isblank(char c)
> >+{
> >+      return (c == ' ' || c == '\t');
> >+}
>
> Use isspace().
>

isspace accepts newlines and carriage-returns too which is not
accepted between elements of a one rule.

> >+      for (i = 0; i < count && data[i]; i ++)
> >...
> >+                      subjectstr[(*label_len) ++] = data[i];
>
> i++ w/o space
>

Notes Taken. Thanks for the review.

Regards,

Darwish

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 2/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel
  @ 2007-10-28 12:46 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-28 12:46 UTC (permalink / raw)
  To: Al Viro; +Cc: casey, akpm, torvalds, linux-security-module, linux-kernel

On 10/28/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Sat, Oct 27, 2007 at 11:01:12AM +0200, Ahmed S. Darwish wrote:
> > The problem here (As discussed in private mails) is that the for loop
> > assumes that the beginning of given user-space buffer is the beginning
> > of a rule. This leads to situations where the rule becomes "ecret 20",
> > or "cret 20" instead of "Secret 20". Big input buffers/files leads
> > smack to recieve a rule like "Secret 20" in fragmented chunks like:
> >
> > write("<lots of rules before ours>\nSec", ..)
> > write("r", 1, ..)
> > write("et 20\n<remaing rules after ours>", ..)
> >
> > Parsing a rule in such tough conditions in _kernel space_ is very
> > hard. I began to feel that it will be much easier if we do the parsing
> > in a userspace utility and let smack accept only small buffers (80 char).
>
> For crying out louf, all it takes is a finite state machine...  BTW, folks,
> your parser *and* input language suck.  Really.  Silently allowing noise
> is Dumb(tm).
>

Ehem .., I really thought about the FSM thing but I thought it won't
be possible with concurrent writes (forgetting that several related
writes is done in one open(),release() session and we can lock writes
in open()).

<Getting back to coding>

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Rule parsing from a virtual FS write() syscall
@ 2007-10-24 11:00 99% Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-24 11:00 UTC (permalink / raw)
  To: linux-kernel; +Cc: casey, viro

Hi all,

In SMACK, some rules are written to a virtual fs file named 
"cipso".

Rule format is

label level[/cat[,cat]]

Under high I/O load we don't recieve the whole rule in one shot.
This means that sometimes the write() operation begins from the 
middle of the rule. Under some conditions, the first rule _letter_
was only recieved while others were recieved in remaining write() 
calls.

Current SMACK versions don't assume fragmented input like above
cases. This means that sometimes bogus rules that does not 
represent users' intent got created.

What is the best way to parse a rule in such hard coditions?

Regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Version 8 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
  @ 2007-10-19 12:39 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-19 12:39 UTC (permalink / raw)
  To: Al Viro
  Cc: Casey Schaufler, torvalds, akpm, linux-security-module, linux-kernel

On 10/18/07, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Thu, Oct 18, 2007 at 05:57:05AM +0100, Al Viro wrote:
> > On Tue, Oct 16, 2007 at 09:17:40PM -0700, Casey Schaufler wrote:
>
> > Think what happens if CPU1 adds to list and CPU2 sees write to smk_known
> > *before* it sees write to ->smk_next.  We see a single-element list and
> > we'll be lucky if that single entry won't be FUBAR.
>
> While we are at it, what protects smack_cipso_count?
> -

My fault. I sent to Casey a one-liner patch to make "smack_cipso_count++"
be protected by the smk_cipsolock spinlock.

We don't need a lock in the reading side since we don't do a write operation
depending on that read, right ?.

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH try #3] Input/Joystick Driver: add support AD7142 joystick driver
  @ 2007-10-16 16:40 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-16 16:40 UTC (permalink / raw)
  To: Bryan Wu
  Cc: Dmitry Torokhov, bryan.wu, Andrey Panin, Roel Kluin, linux-input,
	linux-joystick, linux-kernel, akpm, Jean Delvare

On Tue, Oct 16, 2007 at 02:08:04PM +0800, Bryan Wu wrote:
> On 10/16/07, Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> > On Mon, Oct 15, 2007 at 11:48:17AM -0400, Dmitry Torokhov wrote:
> > > Hi Bryan,
> > >
> > > On 10/15/07, Bryan Wu <bryan.wu@analog.com> wrote:
> > > > +
> > > > +static int ad7142_thread(void *nothing)
> > > > +{
> > > > +       do {
> > > > +               wait_for_completion(&ad7142_completion);
> > > > +               ad7142_decode();
> > > > +               enable_irq(CONFIG_BFIN_JOYSTICK_IRQ_PFX);
> > > > +       } while (!kthread_should_stop());
> > > > +
> > >
> > > No, this is not going to work well:
> > > - you at least need to reinitialize the completion before enabling
> > > IRQ, otherwise you will spin in a very tight loop
> > > - if noone would touch the joystick ad7142_clsoe would() block
> > > infinitely because noone would signal the completion and
> > > ad7142_thread() would never stop.
> > >
> > > Completion is just not a good abstraction here... Please use work
> > > abstraction and possibly a separate workqueue.
> > >
> >
> > Bryan, I'm very interested in the technical advantage of using a completion
> > here.
> >
> You are welcome, I'd like to discuss these things here.
> 
> > In my _not-experienced_ opinion, I remember completions was created mainly for
> > "create_task, wait till task got finished, go on" case. Why using it in a
> > different context while workqueues was created for a similar situation to
> > ad7142 one (non-irq context bottom-half) ?
> 
> I like completion because it is simple to use and understand. Your
> understanding is right. But there is no limit for using different
> context with completion. completion is a wrapper of waitqueue+done
> flag. For some drivers, in process context call
> wait_for_completetion(), then schedule out and in irq handler call
> complete(). This is very simple and helpful for driver design (For
> example, you call dma function to transfer data, then you schedule out
> and then DMA IRQ handler will call complete() to wakeup you).
> 

Thank you for such a useful information.

> But in this driver, a) can not call ad7142_decode() in IRQ handler,
> because it will sleep in IRQ context by calling some i2c API, b) in
> original design, creating a new kthread and using some waitqueue API
> is the same way as using workqueue, c) cannot use completion as Dmitry
> said.
> 
> I am going to use workqueue here.
> 
> Any idea?
> 

I have no better thoughts than the ones provided by Dmitry actually.

> Thanks
> -Bryan Wu

Regards :),

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH try #3] Input/Joystick Driver: add support AD7142 joystick driver
  @ 2007-10-15 18:27 99%   ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-10-15 18:27 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: bryan.wu, Andrey Panin, Roel Kluin, linux-input, linux-joystick,
	linux-kernel, akpm, Jean Delvare

On Mon, Oct 15, 2007 at 11:48:17AM -0400, Dmitry Torokhov wrote:
> Hi Bryan,
> 
> On 10/15/07, Bryan Wu <bryan.wu@analog.com> wrote:
> > +
> > +static int ad7142_thread(void *nothing)
> > +{
> > +       do {
> > +               wait_for_completion(&ad7142_completion);
> > +               ad7142_decode();
> > +               enable_irq(CONFIG_BFIN_JOYSTICK_IRQ_PFX);
> > +       } while (!kthread_should_stop());
> > +
> 
> No, this is not going to work well:
> - you at least need to reinitialize the completion before enabling
> IRQ, otherwise you will spin in a very tight loop
> - if noone would touch the joystick ad7142_clsoe would() block
> infinitely because noone would signal the completion and
> ad7142_thread() would never stop.
> 
> Completion is just not a good abstraction here... Please use work
> abstraction and possibly a separate workqueue.
> 

Bryan, I'm very interested in the technical advantage of using a completion
here.

In my _not-experienced_ opinion, I remember completions was created mainly for
"create_task, wait till task got finished, go on" case. Why using it in a
different context while workqueues was created for a similar situation to
ad7142 one (non-irq context bottom-half) ?

Regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: 2.6.23-git2 buid failure
  @ 2007-10-14 11:18 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-14 11:18 UTC (permalink / raw)
  To: Kamalesh Babulal; +Cc: LKML

On Sat, Oct 13, 2007 at 12:45:47PM +0530, Kamalesh Babulal wrote:
> Hi,
> 
> The 2.6.23-git2 build fails with build error 
> 
>   CC [M]  drivers/mmc/core/core.o
>   CC [M]  drivers/mmc/core/sysfs.o
>   CC [M]  drivers/mmc/core/bus.o
>   CC [M]  drivers/mmc/core/host.o
> drivers/mmc/core/host.c: In function ‘mmc_remove_host’:
> drivers/mmc/core/host.c:146: error: implicit declaration of function ‘led_trigger_unregister’
> drivers/mmc/core/host.c:146: error: ‘struct mmc_host’ has no member named ‘led’
> make[3]: *** [drivers/mmc/core/host.o] Error 1
> make[2]: *** [drivers/mmc/core] Error 2
> make[1]: *** [drivers/mmc] Error 2
> make: *** [drivers] Error 2
> 

You can fix it using this patch: http://lkml.org/lkml/2007/10/12/380
Or the patch titled: mmc-fix-compile-without-led-triggers.patch

Regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH try #2] Input/Joystick Driver: add support AD7142 joystick driver
  @ 2007-10-12 19:21 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-12 19:21 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: Bryan Wu, linux-input, linux-joystick, linux-kernel, akpm

On Fri, Oct 12, 2007 at 01:29:31PM -0400, Dmitry Torokhov wrote:
> Hi Ahmed,
> 

Hi :),

> On 10/12/07, Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> > On Fri, Oct 12, 2007 at 03:38:47PM +0800, Bryan Wu wrote:
> > >
> > > Signed-off-by: Bryan Wu <bryan.wu@analog.com>
> > > ---
> >
> > Hi Bryan,
> >
> > Why creating module's own kthread to call ad7142_decode and process keycodes
> > instead of using a tasklet ?
> >
> 
> Yo can't access i2c from a tasklet context.
> 
> > Isn't disabling device interrupts from the begining of the ISR "ad7142_interrupt"
> > till the kthread "ad7142_thread" got waked-up and scheduled a long time,
> > espicially if there's a high load on the userspace side ?
> >
> 
> It is OK - you disable a specific interrupt line preventing it from
> raising any more IRQs until current one is serviced. 

Won't this affect system responsiveness if the IRQ line was shared ?

>
> This is different from disabling interrupts on CPU.
> 

mm, Why disabling interrupts in general. Doesn't IRQ hanlers of the same kind got
executed in a serialized fashion even on SMPs ?. If so, why not just wakeup our
custom-thread or use workqueues and let them do their business ?

It's the first time for me to read others' patches carefully and kindly ask about
some explanations. I hope I'm not bothering people with my misunderstandings!
(till I get more experienced).


Thanks,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH try #2] Input/Joystick Driver: add support AD7142 joystick driver
  @ 2007-10-12 16:41 99% ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-10-12 16:41 UTC (permalink / raw)
  To: Bryan Wu; +Cc: dmitry.torokhov, linux-input, linux-joystick, linux-kernel, akpm

On Fri, Oct 12, 2007 at 03:38:47PM +0800, Bryan Wu wrote:
>
> Signed-off-by: Bryan Wu <bryan.wu@analog.com>
> ---

Hi Bryan,

Why creating module's own kthread to call ad7142_decode and process keycodes 
instead of using a tasklet ?

Isn't disabling device interrupts from the begining of the ISR "ad7142_interrupt"
till the kthread "ad7142_thread" got waked-up and scheduled a long time,
espicially if there's a high load on the userspace side ?

Minor issues below.

> +
> +/* R    ADC stage 0 - 11 result (uncompensated) actually located in SRAM */
> +#define ADCRESULT_S0		0x0B
> +#define ADCRESULT_S1		0x0C
> +#define ADCRESULT_S2		0x0D
> +#define ADCRESULT_S3		0x0E
> +#define ADCRESULT_S4		0x0F
> +#define ADCRESULT_S5		0x10
> +#define ADCRESULT_S6		0x11
> +#define ADCRESULT_S7		0x12
> +#define ADCRESULT_S8		0x13
> +#define ADCRESULT_S9		0x14
> +#define ADCRESULT_S10		0x15
> +#define ADCRESULT_S11		0x16
> +

Keeping last two lines aligned with their above counterparts ?

> +static int
> +ad7142_probe(struct i2c_adapter *adap, int addr, int kind)
> +{
> +	struct i2c_client *client;
> +	int rc;
> +
> +	client = kmalloc(sizeof(struct i2c_client), GFP_KERNEL);
> +	if (!client)
> +		return -ENOMEM;
> +	memset(client, 0, sizeof(struct i2c_client));

kzalloc.

Regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] NTFS error messages: replace static char pointers by static char arrays
  @ 2007-10-09 22:03 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-09 22:03 UTC (permalink / raw)
  To: Philipp Matthias Hahn; +Cc: Kernel Mailing List

On Tue, Oct 09, 2007 at 08:33:59PM +0200, Philipp Matthias Hahn wrote:
> Hello!
> 
> On Tue, Oct 09, 2007 at 02:40:35PM +0200, Ahmed S. Darwish wrote:
> > On Tue, Oct 09, 2007 at 01:55:42AM +0400, Dmitri Vorobiev wrote:
> > > The patch below contains a small code clean-up for the NTFS driver: all
> > > static char pointers to error message strings have been replaced by 
> > > static char arrays.
> 
>       char *       a = "a"; // pointer and content can be changed

Only the pointer can be changed here. AFAIK "a" is a const string.

> const char *       b = "b"; // the thing pointed to is const

The "const" here is redundant (just useful for forcing the compiler to
prevent us from shooting our feet). The "b" string is already constant.

>       char * const c = "c"; // the pointer is const
> const char * const d = "d"; // pointer and content can't be changed
> 
> void foo(void) {
>         *a = 'A';

This will segfault.

>         a++;
>         *b = 'B'; // error: assignment of read-only location
>         b++;
>         *c = 'C';

Last line will segfault too.

>         c++;      // error: increment  of read-only variable 'c'
>         *d = 'D'; // error: assignment of read-only location
>         d++;      // error: increment  of read-only variable 'd'
> }
> 

Please continue below.

> > Isn't the only difference between char *c = "msg" and char c[] = "msg" is 
> > that the first is a non-const pointer to a const char array while the second 
> > is a modifiable char array ?
> 
> $ cat [ab].c
> const char *a = "a";
> const char b[] = "b";
> $ gcc -c [ab].c
> $ size [ab].o
>    text    data     bss     dec     hex filename
>       2       4       0       6       6 a.o
>       2       0       0       2       2 b.o
> 
> 'a' has two entries: one for the named read-writeable pointer, and one for the
>     anonymous read-only string, the pointer points to.
> 'b' has a single entry: just the named read-only string.
> 

Got the point, Thanks!.

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Stop docproc segfaulting when SRCTREE isn't set.
  @ 2007-10-09 17:51 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-09 17:51 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Rob Landley, akpm, linux-kernel, rdunlap

On Tue, Oct 09, 2007 at 10:24:03AM -0700, Randy Dunlap wrote:
> Ahmed S. Darwish wrote:
> >On Tue, Oct 09, 2007 at 08:55:00AM -0700, Randy Dunlap wrote:
> >>On Tue, 9 Oct 2007 15:03:15 +0200 Ahmed S. Darwish wrote:
> >>
> >>>Hi Rob,
> >>>
> >>>On Tue, Oct 09, 2007 at 01:25:18AM -0500, Rob Landley wrote:
> >>>[...]
> >>>> 	FILE * infile;
> >>>>+
> >>>>+	srctree = getenv("SRCTREE");
> >>>>+	if (!srctree) srctree = getcwd(NULL,0);
> >>>> 	if (argc != 3) {
> >>>> 		usage();
> >>>> 		exit(1);
> >>>$ man getcwd
> >>>
> >>> char *getcwd(char *buf, size_t size);
> >>>      
> >>> As an extension to the POSIX.1 standard, Linux (libc4, libc5, glibc) 
> >>> getcwd() allocates the buffer dynamically using malloc() if buf is NULL 
> >>> on call.
> >>>
> >>>Shouldn't "srctree" be free()ed in case getenv("SRCTREE") failed ?
> >>What is there to free() at that point?  If getenv() fails (i.e.,
> >>the env. variable is not found), it returns NULL.
> >>or do I need another cup of coffee?
> >>
> >
> >I meant if getenv() failed, "srctree = getcwd(NULL, 0)" will let 
> >"srctree" point to a _ malloc()ed _ buffer representing PWD. 
> >As said in the manpage, this buffer needs to be free()ed after usage.
> >Right or I'm the one who needs that cup of coffee :) ?
> 
> so it needs to be freed at program termination, is that what you are
> saying?  That will happen automatically (along with any open files being
> closed, etc.).
> 

I didn't know that leaked mem will be automatically freed at program 
termination. A new info, Thanks!.

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Stop docproc segfaulting when SRCTREE isn't set.
  @ 2007-10-09 17:19 99%     ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-10-09 17:19 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Rob Landley, akpm, linux-kernel, rdunlap

On Tue, Oct 09, 2007 at 08:55:00AM -0700, Randy Dunlap wrote:
> On Tue, 9 Oct 2007 15:03:15 +0200 Ahmed S. Darwish wrote:
> 
> > Hi Rob,
> > 
> > On Tue, Oct 09, 2007 at 01:25:18AM -0500, Rob Landley wrote:
> > [...]
> > >  	FILE * infile;
> > > +
> > > +	srctree = getenv("SRCTREE");
> > > +	if (!srctree) srctree = getcwd(NULL,0);
> > >  	if (argc != 3) {
> > >  		usage();
> > >  		exit(1);
> > 
> > $ man getcwd
> > 
> >  char *getcwd(char *buf, size_t size);
> >       
> >  As an extension to the POSIX.1 standard, Linux (libc4, libc5, glibc) getcwd() 
> >  allocates the buffer dynamically using malloc() if buf is NULL on call.
> > 
> > Shouldn't "srctree" be free()ed in case getenv("SRCTREE") failed ?
> 
> What is there to free() at that point?  If getenv() fails (i.e.,
> the env. variable is not found), it returns NULL.
> or do I need another cup of coffee?
>

I meant if getenv() failed, "srctree = getcwd(NULL, 0)" will let 
"srctree" point to a _ malloc()ed _ buffer representing PWD. 
As said in the manpage, this buffer needs to be free()ed after usage.
Right or I'm the one who needs that cup of coffee :) ?

Regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH -mm] fix wrong /proc/cpuinfo output
  @ 2007-10-09 13:32 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-09 13:32 UTC (permalink / raw)
  To: Akinobu Mita, linux-kernel, Mike Travis, Andrew Morton

On Tue, Oct 09, 2007 at 07:43:21PM +0900, Akinobu Mita wrote:
> This patch fixes the problem introduced by:
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/broken-out/x86-convert-cpuinfo_x86-array-to-a-per_cpu-array.patch
> 

Link is dead, same patch in lkml.org:

http://lkml.org/lkml/2007/9/24/394

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] Stop docproc segfaulting when SRCTREE isn't set.
  @ 2007-10-09 13:03 99% ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-10-09 13:03 UTC (permalink / raw)
  To: Rob Landley; +Cc: akpm, linux-kernel, rdunlap

Hi Rob,

On Tue, Oct 09, 2007 at 01:25:18AM -0500, Rob Landley wrote:
[...]
>  	FILE * infile;
> +
> +	srctree = getenv("SRCTREE");
> +	if (!srctree) srctree = getcwd(NULL,0);
>  	if (argc != 3) {
>  		usage();
>  		exit(1);

$ man getcwd

 char *getcwd(char *buf, size_t size);
      
 As an extension to the POSIX.1 standard, Linux (libc4, libc5, glibc) getcwd() 
 allocates the buffer dynamically using malloc() if buf is NULL on call.

Shouldn't "srctree" be free()ed in case getenv("SRCTREE") failed ?

Regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] NTFS error messages: replace static char pointers by static char arrays
  @ 2007-10-09 12:40 99% ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-10-09 12:40 UTC (permalink / raw)
  To: Dmitri Vorobiev; +Cc: aia21, linux-ntfs-dev, linux-kernel

On Tue, Oct 09, 2007 at 01:55:42AM +0400, Dmitri Vorobiev wrote:
> Hi,
> 
> The patch below contains a small code clean-up for the NTFS driver: all
> static char pointers to error message strings have been replaced by 
> static char arrays.
> 

Hi Dmitri,

Isn't the only difference between char *c = "msg" and char c[] = "msg" is 
that the first is a non-const pointer to a const char array while the second 
is a modifiable char array ?

If so, what's the point of the patch ?

Thanks,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: PROBLEM: kernel 2.6.22.9-cfs-v22 compile warnings
  @ 2007-10-08 18:11 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-08 18:11 UTC (permalink / raw)
  To: Konstantin Oshovskij; +Cc: linux-kernel

Hi Konstantin,

On Mon, Oct 08, 2007 at 03:34:24PM +0300, Konstantin Oshovskij wrote:
>
> Hello,
> i have encountered 2.6.22.9 compile warnings. This is the first time i
> decided to report them. I had various compile warnings with earlier
> kernel versions, its just i didnt had courage to report them :)  I'm
> using instructions from REPORTING-BUGS file as template so please bear
> with me :)
> 

The "may be used uninitialized" errors are false positives from GCC. Mostly
this happens from code paths like: 

int x, y; 
set_method(&x); 
y = x;

> fs/xfs/xfs_bmap.c: In function 'xfs_bmap_rtalloc':
> fs/xfs/xfs_bmap.c:2650: warning: 'rtx' is used uninitialized in this
> function
> 

Hidden by uninitialized_var() macro in latest pull. This macro silence
the gcc by using the trick: #define uninitialized_var(x) x = x

> function
> ipc/msg.c:390: warning: 'setbuf.mode' may be used uninitialized in
> this function
>   CC      ipc/sem.o
> ipc/sem.c: In function 'sys_semctl':
> ipc/sem.c:861: warning: 'setbuf.uid' may be used uninitialized in this
> function
> ipc/sem.c:861: warning: 'setbuf.gid' may be used uninitialized in this
> function
> ipc/sem.c:861: warning: 'setbuf.mode' may be used uninitialized in
> this function
> 

Already hidden now by the uninitialized_var() macro.

> drivers/pci/search.c: In function 'pci_find_slot':
> drivers/pci/search.c:99: warning: 'pci_find_device' is deprecated
> (declared at include/linux/pci.h:477)

pci_find_slot is using pci_find_device on purpose here (equivalent to the
safe pci_get_slot method).

> drivers/pci/search.c: At top level:
> drivers/pci/search.c:434: warning: 'pci_find_device' is deprecated
> (declared at drivers/pci/search.c:241)
> drivers/pci/search.c:434: warning: 'pci_find_device' is deprecated
> (declared at drivers/pci/search.c:241)
> 

False positives from function definition and from the innocent EXPORT_SYMBOL
macro (It makes the method available to kernel modules).

Regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [Oops] on 2.6.23-rc9 sysRq Show Tasks (t)
  @ 2007-10-07 19:39 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-07 19:39 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: linux-kernel

On Sun, Oct 07, 2007 at 01:12:38AM +0400, Alexey Dobriyan wrote:
> On Sat, Oct 06, 2007 at 10:14:06PM +0200, Ahmed S. Darwish wrote:
> > Pressing sysRq+T always produce an Oops for every running system task (94 
> > Oopses, that's a record ;)).
> 
> uh-oh. For every sleeping task, I think.
> 
> > The bug is 100% reproducable. Should I begin bisecting/investigating the 
> > issue or it's a known problem ?
> 
> Start with some old kernel, like mmm.. 2.6.0. The fact that same behaviour
> was present there may make you think about faulty assumptions you've
> made.
> 

Yeah I understood my mistake (not an Oops, a normal behaviour). 
Thanks for your advice :).

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [Oops] on 2.6.23-rc9 sysRq Show Tasks (t)
  @ 2007-10-06 20:52 99% ` Ahmed S. Darwish
    1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-10-06 20:52 UTC (permalink / raw)
  To: linux-kernel

On Sat, Oct 06, 2007 at 10:14:05PM +0200, ahmed wrote:
> Hi all,
> 
> Pressing sysRq+T always produce an Oops for every running system task (94 
> Oopses, that's a record ;)).
> The bug is 100% reproducable. Should I begin bisecting/investigating the 
> issue or it's a known problem ?
>

Shame, This is not an Oops at all. Really sorry.

/me wondering about my look now posting a normal message as an Ooops a day 
before the stable release :(.

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2/3] MIPS: Remove deprecated IRQ flags (SA_*)
  @ 2007-09-26 22:35 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-09-26 22:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: akpm, ralf

Hi Ralf,

A patch to stop using deprecated IRQ flags. The new IRQF_* macros are used
instead.


Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---

diff --git a/arch/mips/pci/ops-pmcmsp.c b/arch/mips/pci/ops-pmcmsp.c
index 09fa007..a86a189 100644
--- a/arch/mips/pci/ops-pmcmsp.c
+++ b/arch/mips/pci/ops-pmcmsp.c
@@ -404,7 +404,7 @@ int msp_pcibios_config_access(unsigned char access_type,
 	if (pciirqflag == 0) {
 		request_irq(MSP_INT_PCI,/* Hardcoded internal MSP7120 wiring */
 				bpci_interrupt,
-				SA_SHIRQ | SA_INTERRUPT,
+				IRQF_SHARED | IRQF_DISABLED,
 				"PMC MSP PCI Host",
 				preg);
 		pciirqflag = ~0;
diff --git a/arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c b/arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c
index 6fa8572..ab96a2d 100644
--- a/arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c
+++ b/arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c
@@ -163,7 +163,7 @@ static int msp_hwbutton_register(struct hwbutton_interrupt *hirq)
 		CIC_EXT_SET_ACTIVE_HI(cic_ext, hirq->eirq);
 	*CIC_EXT_CFG_REG = cic_ext;
 
-	return request_irq(hirq->irq, hwbutton_handler, SA_INTERRUPT,
+	return request_irq(hirq->irq, hwbutton_handler, IRQF_DISABLED,
 				hirq->name, (void *)hirq);
 }
 

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* i386: Fix null interrupt handler (ignore_int) message ?
@ 2007-09-24 22:08 99% Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-09-24 22:08 UTC (permalink / raw)
  To: linux-kernel; +Cc: hpa

Hi all,

I'm getting little confused by some ignore_int (null interrupt handler) code in
head.S. Code notifies the user about the unknown raised interrupt by below
string:

int_msg:
	.asciz "Unknown interrupt or fault at EIP %p %p %p\n"

and prints it using below code path:

ignore_int:
	pushl %eax; pushl %ecx; pushl %edx; pushl %es; pushl %ds
	[...]
	pushl 16(%esp); pushl 24(%esp); 
	pushl 32(%esp); pushl 40(%esp); 
	pushl $int_msg
	[...]
	call printk

** But here's the state of stack before calling printk:

     ???            <-- 40(%esp)             
     ???            <-- 36(%esp)
     --> (Automatically pushed by the processor)
     %eflags        <-- 32(%esp)
     %cs	    <-- 28(%esp)
     %eip	    <-- 24(%esp)
     error-code     <-- 20(%esp)
     --> (Pushed by first lines of ignore_int)
     %eax	    <-- 16(%esp)
     %ecx	    <--	12(%esp)
     %edx	    <-- 8(%esp)
     %es	    <-- 4(%esp)
     %ds	    <-- %esp      

Does 40(%esp) hold a meaningfule value here ?. Also why passing 4 arguments after
the string to prinkt while the string only has 3 conversion specifications (i.e.,
3 * %p) ?.

Best regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: PROBLEM: System Freeze on Particular workload with kernel 2.6.22.6
  @ 2007-09-20 15:24 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-09-20 15:24 UTC (permalink / raw)
  To: Jarek Poplawski
  Cc: Low Yucheng, Oleg Verych, linux-kernel, linux-mm, Andrew Morton

On Thu, Sep 20, 2007 at 12:00:31PM +0200, Jarek Poplawski wrote:
> On 19-09-2007 21:25, Ahmed S. Darwish wrote:
> > Hi Low,
> > 
> > On Wed, Sep 19, 2007 at 12:16:39PM -0400, Low Yucheng wrote:
> >> There are no additional console messages.
> >> Not sure what this is: * no relevant Cc (memory management added)
> > 
> > Relevant CCs means CCing maintainers or subsystem mailing lists related to your
> > bug report. i.e, if it's a networking bug, you need to CC the linux kernel
> > networking mailing list. If it's a kobject bug, you need to CC its maintainer
> > (Greg) and so on.
> 
> So, which one do you recommend here?
> 

I'm not really sure, just wanted to solve Jarek's confusion :).

Regards,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: PROBLEM: System Freeze on Particular workload with kernel 2.6.22.6
  @ 2007-09-19 19:25 99%     ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-09-19 19:25 UTC (permalink / raw)
  To: Low Yucheng; +Cc: Oleg Verych, linux-kernel, linux-mm, Andrew Morton

Hi Low,

On Wed, Sep 19, 2007 at 12:16:39PM -0400, Low Yucheng wrote:
> There are no additional console messages.
> Not sure what this is: * no relevant Cc (memory management added)

Relevant CCs means CCing maintainers or subsystem mailing lists related to your
bug report. i.e, if it's a networking bug, you need to CC the linux kernel
networking mailing list. If it's a kobject bug, you need to CC its maintainer
(Greg) and so on.

Regards,  

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [i386] Questions regarding provisional page tables initialization
  @ 2007-07-02 15:43 99%           ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-07-02 15:43 UTC (permalink / raw)
  To: Brian Gerst; +Cc: Andreas Schwab, Jeremy Fitzhardinge, linux-kernel

On Mon, Jul 02, 2007 at 07:34:20AM -0400, Brian Gerst wrote:
> Ahmed S. Darwish wrote:
> > now back to head.S code:
> >  	leal    0x007(%edi),%ecx	/* Create PDE entry */
> > 
> > Isn't the above line the same condition (bytes, not bits displacement) ?. 
> > Thanks for your patience !.
> 
> The leal instruction (Load Effective Address) is often used as a way to
> add a constant to one register and store the result in another register
> in a single instruction.
> [...]

At last I got it due to all of everybody's very nice explanations :). 
Here's the provisional page tables intialization scenario:

We want to store pg0 pte addresses to high 20bits swapper_pg_dir entries,
we also want the PRESENT,RW,USER flags be set in those entries. This is 
done by  getting the address of each pg0 entry and adding 7 to it (Brian's
note). Since pg0 entires address are page aligned(Andreas, Jeremy notes),
adding 7 will assure that the first 3 bits are set without affecting the
high 20 bits.

Big Thanks!,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [i386] Questions regarding provisional page tables initialization
  @ 2007-07-02  1:13 99%   ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-07-02  1:13 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: linux-kernel

Hi Jeremy,

On Sun, Jul 01, 2007 at 03:19:30PM -0700, Jeremy Fitzhardinge wrote:
> Ahmed S. Darwish wrote:
> >Hi list,
> >
> >AFAIK, in the initializaion phase, kernel builds pages tables with two
> >mappings, identity and PAGE_OFFSET + C mapping. The provisional _global
> >directory_ is contained in swapper_pg_dir variable. while the provisional 
> >_page tables_ are stored starting from pg0, right after _end.
> >
> >There're some stuff that confused me for a full day about the code (head.S)
> >that  accomplishes the above words:
> >
> >	movl $(pg0 - __PAGE_OFFSET), %edi
> >	movl $(swapper_pg_dir - __PAGE_OFFSET), %edx	
> >	movl $0x007, %eax			/* 0x007 = PRESENT+RW+USER */
> >10:
> >	leal $0x007(%edi),%ecx			/* Create PDE entry */
> >
> >What does the address of 7 bytes displacement after %edi - the physical 
> >address
> >of pg0 - represent ?. Why not just putting the address of %edi (the 
> >address of
> >pagetable cell to be mapped by swapper_pg_dir) in %ecx without 
> >displacement?
> >  
> 
> The pte format contains the pfn in the top 20 bits, and flags in the 
> lower 12 bits.  As the comment says "0x007 = PRESENT+RW+USER".
> 

yes, but isn't the displacement here (0x007) a _bytes_ displacement ?. so
effectively, %ecx now contains physical address of pg0 + 7bytes. Is it A 
meaningful place/address ?.

> >        page_pde_offset = (__PAGE_OFFSET >> 20)
> >	movl %ecx,(%edx)			/* Store identity PDE entry 
> >	*/
> >	movl %ecx,page_pde_offset(%edx)		/* Store kernel PDE entry */
> >
> >Why the pde_offset is PAGE_OFFSET >> 20 instead of PAGE_OFFSET >> 22 ?
> >* 22 to right shift the whole page_shift (12) and pgdir_shift (10) bits.
> >  
> 
> As Andreas said, its (PAGE_OFFSET >> 22) << 2.
> 

Great!, Thanks a lot.

> >        [...]
> >	/* Initialize the 1024 _page table_ cells with %eax (0x007) */
> >	movl $1024, %ecx
> >11:
> >	stosl
> >	addl $0x1000,%eax
> >	loop 11b
> >
> >The page table entries beginning from pg0 (pointed by %edi) and following 
> >pages are initialized with  the series 7 + 8 + 8 + ... for each cell. This 
> >series has
> >the property of setting the PRESENT+RW+USER bits in the whole entries to 1 
> >but it
> >sets lots of the entries BASE address to 0 too. Why is this done ?
> >  
> 
> I don't follow you.  Are you overlooking the 'L' on stosl?
> 

Sorry for not making the question clear. my question was that the first entry in
the page table pointed by (%edi) is initialize with %eax = 0x007, a reasonable
value (setting the 3 pte flags). Beginning from entry 2, they got initialized
with a value = "new %eax = old %eax + 8", generating a table of entries
initialized with 7, 15, 31, .. . While this scheme makes the 3 PRESENT, RW 
and USER flags set, it makes alot of "pte"s with equivalent "pfn"s. Here comes 
my wonder, why initializing pg0 that way ?.

Thanks,

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: Fork Bombing Attack
  @ 2007-05-18 13:19 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-05-18 13:19 UTC (permalink / raw)
  To: Anand Jahagirdar; +Cc: Valdis.Kletnieks, linux-kernel

On 5/18/07, Anand Jahagirdar <anandjigar@gmail.com> wrote:
> Hello All
>            I tried to execute a program which creates 8152 process.(
> i=0; while( i<14) i++ fork(); )  with ulimit 8200. This program
> created 8152 processes and then stopped and came back to command
> prompt. this proves that my machine do have sufficient resources to
> create 8000 processes.
>
>            I found one more interesting thing on the same machine
> having FC6 distribution and Linux Kernel 2.6.18. i have set "ulimit -u
> 100". after setting this limit i tried to execute fork bombing program
> with guest account. after executing it
>
> expected result:-  guest uesr should not able to fork another single
> process when it reaches to 100 processes count.
>
> actual result :-  kernel allow me to create another processes without
> giving error. due to this i tried to execute same fork bombing program
> on another terminal with guest account and this fork bombing attack
> killed the box completely and machine needed reboot.
>

I think if you want resource limiting per _UID_ (and not per _process_
as you did), you should use PAM module pam_limits.so. You can edit
those limits using the file /etc/security/limits.conf

Regards,
-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: Student Project Ideas
  @ 2007-03-29 20:44 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-29 20:44 UTC (permalink / raw)
  To: Russ Meyerriecks; +Cc: linux-kernel

On Thu, Mar 29, 2007 at 05:04:08AM -0500, Russ Meyerriecks wrote:
> Hi all,
>  I've been hacking on the Linux kernel all semester for my OS:
> Internals class. We are given full autonomy in picking our final
> programming project and I would love for mine to be /useful/ for the
> Linux kernel and not just a theoretical exorcise. If anybody has any
> bug fixes or features maybe they never got around to, and would be
> suitable for this situation, I would love to hear about them.
> 

I'm a college student too and I wished a wish like that in the past. After 
watching the development process for a while, I realized that somehow
a college final project won't fit with the linux kernel project.
Everything here is done by _evolution_ not a revolution, you'll even see the 
highest matured programmers in this project send little patches day by day. 

And the problem that you can't meet your PH.D and tell him/her: hey, I have
a patch or two, they simply don't understand that ;).

Second, I think it's very hard to make a considerable project in the kernel
without doing some little patches here and there at first. Google for kernel
newbies and kernel janitors.

Regards,

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] IRQ: Check for PERCPU flag only when adding first irqaction.
  2007-03-26 19:14 99% [PATCH] IRQ: Check for PERCPU flag only when adding first irqaction Ahmed S. Darwish
@ 2007-03-27  8:54 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-27  8:54 UTC (permalink / raw)
  To: linux-kernel

On Mon, Mar 26, 2007 at 09:14:55PM +0200, ahmed wrote:
> Hi,
> 
> An irqaction structure won't be added to the IRQ line irqaction list if they
> don't agree wrt the IRQF_PERCPU flag. Only check and set this flag in IRQ
> descriptor `status' field when the first irqaction is added to the line list.
> 
> 
> Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
> ---
> Patch over 2.6.21-rc5.

Maybe just a better description (with the same patch below):

An irqaction structure won't be added to an IRQ descriptor irqaction list
if it don't agree with other irqactions on the IRQF_PERCPU flag. Don't 
check for this flag to change IRQ descriptor `status' for every irqaction
added to the list, Doing the check only for the first irqaction added is
enough.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 5597c15..ea82a54 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -317,10 +317,7 @@ int setup_irq(unsigned int irq, struct irqaction *new)
 	}
 
 	*p = new;
-#if defined(CONFIG_IRQ_PER_CPU)
-	if (new->flags & IRQF_PERCPU)
-		desc->status |= IRQ_PER_CPU;
-#endif
+
 	/* Exclude IRQ from balancing */
 	if (new->flags & IRQF_NOBALANCING)
 		desc->status |= IRQ_NO_BALANCING;
@@ -328,6 +325,11 @@ int setup_irq(unsigned int irq, struct irqaction *new)
 	if (!shared) {
 		irq_chip_set_defaults(desc->chip);
 
+#if defined(CONFIG_IRQ_PER_CPU)
+		if (new->flags & IRQF_PERCPU)
+			desc->status |= IRQ_PER_CPU;
+#endif
+		
 		/* Setup the type (level, edge polarity) if configured: */
 		if (new->flags & IRQF_TRIGGER_MASK) {
 			if (desc->chip && desc->chip->set_type)


-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] net: tun/tap: fixed hw address handling
  2007-03-26 20:55 99% ` Ahmed S. Darwish
@ 2007-03-26 21:05 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-26 21:05 UTC (permalink / raw)
  To: Brian Braunstein
  Cc: Max Krasnyansky, vtun, akpm, jgarzik, netdev, linux-kernel

On Mon, Mar 26, 2007 at 10:55:11PM +0200, ahmed wrote:
> On Sun, Mar 25, 2007 at 01:29:29AM -0700, Brian Braunstein wrote:
> > --- linux-2.6.20.4-ORIG/drivers/net/tun.c	2007-03-23 
> > 12:52:51.000000000 -0700
> > +++ linux-2.6.20.4/drivers/net/tun.c	2007-03-25 00:44:20.000000000 -0700
> > @@ -18,6 +18,10 @@
> > /*
> >  *  Changes:
> >  *
> > + *  Brian Braunstein <linuxkernel@bristyle.com> 2007/03/23
> > + *    Fixed hw address handling.  Now net_device.dev_addr is kept 
> > consistent
> 
> Your mailer still wrap the long lines mistakenly as it did in the first
> version of the patch.
> 

It seems a bug in my mutt mail reader (not a feature, it displays other 
mails long lines without wrapping), sorry.

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] net: tun/tap: fixed hw address handling
  @ 2007-03-26 20:55 99% ` Ahmed S. Darwish
  2007-03-26 21:05 99%   ` Ahmed S. Darwish
  0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-03-26 20:55 UTC (permalink / raw)
  To: Brian Braunstein
  Cc: Max Krasnyansky, vtun, akpm, jgarzik, netdev, linux-kernel

On Sun, Mar 25, 2007 at 01:29:29AM -0700, Brian Braunstein wrote:
> 
> From: Brian Braunstein <linuxkernel@bristyle.com>
> 

No need for this line. This line is used when you _forward_ another patch
from others. Signed-off-by is enough

> 
> Signed-off-by: Brian Braunstein <linuxkernel@bristyle.com>
> 
> ---
> 
> Kernel Version: 2.6.20.4
> 

It's always better to generate the patch against the latest -rc kernel.

> --- linux-2.6.20.4-ORIG/drivers/net/tun.c	2007-03-23 
> 12:52:51.000000000 -0700
> +++ linux-2.6.20.4/drivers/net/tun.c	2007-03-25 00:44:20.000000000 -0700
> @@ -18,6 +18,10 @@
> /*
>  *  Changes:
>  *
> + *  Brian Braunstein <linuxkernel@bristyle.com> 2007/03/23
> + *    Fixed hw address handling.  Now net_device.dev_addr is kept 
> consistent

Your mailer still wrap the long lines mistakenly as it did in the first
version of the patch.

Regards,

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* [PATCH] IRQ: Check for PERCPU flag only when adding first irqaction.
@ 2007-03-26 19:14 99% Ahmed S. Darwish
  2007-03-27  8:54 99% ` Ahmed S. Darwish
  0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-03-26 19:14 UTC (permalink / raw)
  To: linux-kernel

Hi,

An irqaction structure won't be added to the IRQ line irqaction list if they
don't agree wrt the IRQF_PERCPU flag. Only check and set this flag in IRQ
descriptor `status' field when the first irqaction is added to the line list.


Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---

Patch over 2.6.21-rc5.

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 5597c15..ea82a54 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -317,10 +317,7 @@ int setup_irq(unsigned int irq, struct irqaction *new)
 	}
 
 	*p = new;
-#if defined(CONFIG_IRQ_PER_CPU)
-	if (new->flags & IRQF_PERCPU)
-		desc->status |= IRQ_PER_CPU;
-#endif
+
 	/* Exclude IRQ from balancing */
 	if (new->flags & IRQF_NOBALANCING)
 		desc->status |= IRQ_NO_BALANCING;
@@ -328,6 +325,11 @@ int setup_irq(unsigned int irq, struct irqaction *new)
 	if (!shared) {
 		irq_chip_set_defaults(desc->chip);
 
+#if defined(CONFIG_IRQ_PER_CPU)
+		if (new->flags & IRQF_PERCPU)
+			desc->status |= IRQ_PER_CPU;
+#endif
+		
 		/* Setup the type (level, edge polarity) if configured: */
 		if (new->flags & IRQF_TRIGGER_MASK) {
 			if (desc->chip && desc->chip->set_type)

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com

^ permalink raw reply	[relevance 99%]

* Re: PATCH: tun/tap driver hw address handling
  @ 2007-03-24 17:04 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-24 17:04 UTC (permalink / raw)
  To: Brian Braunstein; +Cc: Max Krasnyansky, torvalds, linux-kernel, rajesh_mish

Hi Brian,

On Sat, Mar 24, 2007 at 01:56:50AM -0700, Brian Braunstein wrote:
> 
> Linus,
> 
>  According to Documentation/SubmittingPatches "bug fixes" or "obvious" 
> changes
>  should CCed to you, so this is why I have done this.
>

IMHO these days patches got reviewed on LKML, then tested enough on the
unstable -mm tree then it got added to mainline kernel. Subsystem maintaners
can also add patches directly to mainline if they're trivial enough.
 
> Note: This entire email can be found at
> http://bristyle.com/share/patch-tuntap-hw_addr_handling.txt
> 

I think No need for such two lines. everyone uses his favourite LKML archive.

>  Summary:
>    Fix tun/tap driver's handling of hw addresses.  Specifically, ensure 
> that
>    when the tun.dev_addr field is set, the net_device.dev_addr field gets
>    set to the same value.
> 
>  Background:
>    The device hw address is stored in 2 places, in the tun.dev_addr field,
>    and of course the net_device struct's dev_addr field.  It really 
> seems to
>    me that the tun.dev_addr field is redundant, and that anywhere it is 
> used

Editor/mailer wrapping your lines badly ?

> 
> --- linux-2.6.20.4-ORIG/drivers/net/tun.c       2007-03-23 
> 12:52:51.000000000 -0700
> +++ linux-2.6.20.4/drivers/net/tun.c    2007-03-24 01:36:59.000000000 -0700
> @@ -18,6 +18,11 @@

Please reread SubmittingPatches to know the canonical patch format (missing
Signed-off-by and others).

> /*
>  *  Changes:
>  *
> + *  Brian Braunstein <linuxkernel@bristyle.com> 2007/03/23
> + *    Fixed hw address handling.  Now net_device.dev_addr is kept 
> consistent
[Remaing patch]

Patch can't be applied or even read cause your mailer has mistakenly wrapped
its lines.

Regards,

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Re: i386: Why putting __USER_DS in kernel threads stack initialization?
  @ 2007-03-21 19:25 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-21 19:25 UTC (permalink / raw)
  To: linux-os (Dick Johnson); +Cc: Linux kernel

On Mon, Mar 19, 2007 at 07:23:25AM -0400, linux-os (Dick Johnson) wrote:
> 
> On Sun, 18 Mar 2007, Ahmed S. Darwish wrote:
> 
> > Hi list,
> >
> > Reading the kernel threads initialization code I see:
> >
> > int kernel_thread(...) {
> >
> > 	struct pt_regs regs;
> > 	memset(&regs, 0, sizeof(regs));
> > 	[...]
> > **	regs.xds = __USER_DS;
> > **	regs.xes = __USER_DS;
> > 	[...]
> > 	/* Ok, create the new process.. */
> > 	return do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0, &regs, \
> > 	       	       0, NULL, NULL);
> >
> > Continuing with the code, the threads stack (beginning from %esp) is
> > initialized with the passed *regs from do_fork:
> >
> > int copy_thread(..., struct task_struct *p, struct pt_regs *regs) {
> >
> > 	struct pt_regs * childregs;
> > 	struct task_struct *tsk;
> > 	childregs = task_pt_regs(p);
> > **	*childregs = *regs;
> > 	[...]
> > ** 	p->thread.esp = (unsigned long) childregs;
> >
> >
> > So the question is what will a _kernel_ thread do with the Usermode Segment
> > address ?
> >
> > Thanks,
> >
> > P.S. I've tried commenting out both lines which led to a non functional init,
> > Also setting them to __USER_DS made init start but stopped issuing the error:
> > `Panic: Segment violation at 0x8049798 - Sleeping for 30 seconds'
> >

Sorry, I meant "setting them to __KERNEL_DS" here.

> 
> You might be confusing two routines. The kernel thread routine sets
> DS and ES to the kernel data segment, __KERNEL_DS, not the user data
> segment. 

And that's what's _not_ happening in the code as I mentioned in original post.

> This is so the kernel thread can access the kernel data. Note
> that this is done by putting the values in the pt_regs structure so
> it doesn't happen 'now', but after the fork.

I've searched the code for such case (setting xds to __KERNEL_DS _After_ 
copy_thread()) with no success. As I understand, the kernel thread 
executes the passed function immediately (when given control by scheduler):

i386/kernel/process::kernel_thread():
**	regs.ebx = (unsigned long) fn;
	regs.edx = (unsigned long) arg;
	regs.xds = __USER_DS;
	regs.xes = __USER_DS;
	regs.xfs = __KERNEL_PDA;
	regs.orig_eax = -1;
**	regs.eip = (unsigned long) kernel_thread_helper;
	do_fork(...)

entry.S::kernel_thread_helper (removing CFI_* pseudo ops):

   ENTRY(kernel_thread_helper)
	pushl $0		
	movl %edx,%eax
	push %edx
**	call *%ebx
	push %eax
	call do_exit
	
Am I interpreting the forking process completely wrong?. I'm just curious why 
the __USER_DS is playing a vital rule in kernel threads regs/stack ?

Thanks alot,

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Re: i386: Why putting __USER_DS in kernel threads stack initialization?
  2007-03-18 22:58 99% i386: Why putting __USER_DS in kernel threads stack initialization? Ahmed S. Darwish
@ 2007-03-18 23:15 99% ` Ahmed S. Darwish
    1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-18 23:15 UTC (permalink / raw)
  To: linux-kernel

On Mon, Mar 19, 2007 at 12:58:31AM +0200, ahmed wrote:
> 
> P.S. I've tried commenting out both lines which led to a non functional init,
> Also setting them to __USER_DS made init start but stopped issuing the error:
> `Panic: Segment violation at 0x8049798 - Sleeping for 30 seconds'
> 

Sorry, I meant setting them to __KERNEL_DS.

Thanks,

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* i386: Why putting __USER_DS in kernel threads stack initialization?
@ 2007-03-18 22:58 99% Ahmed S. Darwish
  2007-03-18 23:15 99% ` Ahmed S. Darwish
    0 siblings, 2 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-18 22:58 UTC (permalink / raw)
  To: linux-kernel

Hi list,

Reading the kernel threads initialization code I see:

int kernel_thread(...) {

	struct pt_regs regs;
	memset(&regs, 0, sizeof(regs));
	[...]
**	regs.xds = __USER_DS;
**	regs.xes = __USER_DS;
	[...]
	/* Ok, create the new process.. */
	return do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0, &regs, \
	       	       0, NULL, NULL);

Continuing with the code, the threads stack (beginning from %esp) is
initialized with the passed *regs from do_fork:

int copy_thread(..., struct task_struct *p, struct pt_regs *regs) {

	struct pt_regs * childregs;
	struct task_struct *tsk;
 	childregs = task_pt_regs(p);
**	*childregs = *regs;
	[...]
** 	p->thread.esp = (unsigned long) childregs;


So the question is what will a _kernel_ thread do with the Usermode Segment
address ?

Thanks,

P.S. I've tried commenting out both lines which led to a non functional init,
Also setting them to __USER_DS made init start but stopped issuing the error:
`Panic: Segment violation at 0x8049798 - Sleeping for 30 seconds'

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH 2.6.21-rc4] kernel/exit: Fix a comment and code contradiction
  @ 2007-03-17 15:00 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-17 15:00 UTC (permalink / raw)
  To: hannes-kernel; +Cc: kernel-janitors, linux-kernel, trivial

[Johannes please use replay-to-all to notify all readers]

On 2007-03-17 9:45:36 Johannes Weiner wrote:
> On Sat, Mar 17, 2007 at 08:21:32AM +0200, Ahmed S. Darwish wrote:
> > Comment in release_task() claims that group leader's parent process 
> > is signalled only if it desires so, which is not true.
>
> AFAIS, `if it wants notification' means, it does not ignore its children
> via SIG_IGN als handler for SIGCHLD.
>

AFAIK, exit_signal = -1 means that the parent don't want to be signalled,
like what happenes when using CLONE_THREAD. 

But it's even signalled in that case (after issuing a BUG):
   BUG_ON(leader->exit_signal == -1);
   do_notify_parent(leader, leader->exit_signal);

> do_notify_parent() checks if the parent wants to get informed about the
> child states.
>

Yes it does the check but it notifies the given task_struct anyway:

	BUG_ON(sig == -1);
	[ Continue parent notification normally ]
-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.21-rc4] kernel/exit: Fix a comment and code contradiction
@ 2007-03-17  6:21 99% Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-03-17  6:21 UTC (permalink / raw)
  To: kernel-janitors, linux-kernel; +Cc: trivial

Hi list,

Comment in release_task() claims that group leader's parent process 
is signalled only if it desires so, which is not true.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---

To save your time, here's the contradictory code which don't appear in 
the patch (appears after its last line):

      leader = p->group_leader;
      if (leader != p && thread_group_empty(leader) && leader->exit_state == EXIT_ZOMBIE) {
		BUG_ON(leader->exit_signal == -1);
		do_notify_parent(leader, leader->exit_signal);


diff --git a/kernel/exit.c b/kernel/exit.c
index f132349..4a0a35f 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -152,7 +152,7 @@ repeat:
 	/*
 	 * If we are the last non-leader member of the thread
 	 * group, and the leader is zombie, then notify the
-	 * group leader's parent process. (if it wants notification.)
+	 * group leader's parent process.
 	 */
 	zap_leader = 0;
 	leader = p->group_leader;

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Re: [PATCH] drivers/media/video/videocodec.c: check kmalloc() return value.
  @ 2007-03-12 10:45 99% ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-03-12 10:45 UTC (permalink / raw)
  To: Amit Choudhary; +Cc: Linux Kernel

Hi Amit,

On Thu, Mar 08, 2007 at 11:14:01PM -0800, Amit Choudhary wrote:
> Description: Check the return value of kmalloc() in function 
> videocodec_build_table(), in file drivers/media/video/videocodec.c.

No need for `Description:'. This line is automatically put in the logs 
as a patch description if the patch got accepted. 

It's better not to use very large lines. 

Also there's no need to specify the exact function in the log, it's already
displayed in the patch.

> 
> Signed-off-by: Amit Choudhary <amit2030@gmail.com>
> 

As said in Documentation/SubmittingPatches put a "---" line after
Signed-off-by signature.

Thanks,

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Video GL rendering worked only between 2.6.20 and 2.6.21-rc1
@ 2007-02-23 18:07 99% Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-23 18:07 UTC (permalink / raw)
  To: linux-kernel

Hi list,

Aiglx/Beryl effects (transparency and other stuff) on windows that display 
video worked magically for the first time in a pull point between 2.6.20 and 
2.6.21-rc1. Unfortunately It doesn't work again now in 2.6.21-rc1 and even in 
2.6.20-mm{1,2}.

I'm not able to find the good commit again :(. Could someone please tell
me the files that is most probably responsible for video GL rendering 
so I can track their changes and find the good commit.

The machine is a Centrino laptop with an i810 card. So I guess those are 
the responsible files:
    
    drivers/char/drm/i810_*.c
    drivers/video/i810/*

Any more probably responsible files? 

Thanks,

-- 
Ahmed S. Darwish
http://darwish.07.googlepages.com


^ permalink raw reply	[relevance 99%]

* Re: [patch 1/2] natsemi: Add support for using MII port with no PHY
  @ 2007-02-14 13:28 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-14 13:28 UTC (permalink / raw)
  To: Mark Brown; +Cc: Tim Hockin, Jeff Garzik, netdev, linux-kernel

On Wed, Feb 14, 2007 at 10:02:04AM +0000, Mark Brown wrote:

> Signed-Off-By: Mark Brown <broonie@sirena.org.uk>
> 
[...]
> -		if (np->phy_addr_external == PHY_ADDR_NONE) {
> +		/* If we're ignoring the PHY it doesn't matter if we can't
> +		 * find one. */
> +		if (!np->ignore_phy && np->phy_addr_external == PHY_ADDR_NONE) {
[...]
> +	if (!np->ignore_phy) {
> +		/* The link status field is latched: it remains low
> +		 * after a temporary link failure until it's read. We
> +		 * need the current link status, thus read twice.
> +		 */
> +		mdio_read(dev, MII_BMSR);
> +		bmsr = mdio_read(dev, MII_BMSR);
[...]
>  	/*
> +	 * If we're ignoring the PHY then autoneg and the internal
> +	 * transciever are really not going to work so don't let the
> +	 * user select them.
> +	 */
> +	if (np->ignore_phy && (ecmd->autoneg == AUTONEG_ENABLE ||

A trivial comment actually, Is there a point to write multi-line comments 
in two different formats ?

Thanks,

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 2.6.20] isdn-capi: Use ARRAY_SIZE macro when appropriate
  @ 2007-02-07 19:41 99%         ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-07 19:41 UTC (permalink / raw)
  To: Philippe De Muyter
  Cc: Joe Perches, kkeil, kai.germaschewski, linux-kernel, isdn4linux

On Tue, Feb 06, 2007 at 10:18:14PM +0100, Philippe De Muyter wrote:
> On Tue, Feb 06, 2007 at 10:41:30PM +0200, Ahmed S. Darwish wrote:
> >  
> > -    for (i=nelem-1; i >= 0; i--) {
> > +    for (i = ARRAY_SIZE(procfsentries) - 1; i >= 0; i--) {
> 
> I would write such decrementing loops as :
> 
>        for (i = ARRAY_SIZE(procfsentries); --i >= 0; ) {
> 
> Long time ago, that produced better code.  I did not check recently though.
[...]
> > -    for (i=nelem-1; i >= 0; i--) {
> > +    for (i = ARRAY_SIZE(procfsentries) - 1; i >= 0; i--) {
> 
> Same here

Hi Philippe,

Won't this hurt readability ?. I'm not a gcc guru anyway to have an
opinion on such stuff :).

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] drm: Use ARRAY_SIZE macro when appropriate
                     ` (8 preceding siblings ...)
  2007-02-06 16:06 99% ` [PATCH 2.6.20] drivers/md.c: " Ahmed S. Darwish
@ 2007-02-06 16:10 99% ` Ahmed S. Darwish
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:10 UTC (permalink / raw)
  To: airlied; +Cc: linux-kernel, dri-devel

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/char/drm/drm_proc.c b/drivers/char/drm/drm_proc.c
index 62d5fe1..8943ad1 100644
--- a/drivers/char/drm/drm_proc.c
+++ b/drivers/char/drm/drm_proc.c
@@ -72,7 +72,7 @@ static struct drm_proc_list {
 #endif
 };
 
-#define DRM_PROC_ENTRIES (sizeof(drm_proc_list)/sizeof(drm_proc_list[0]))
+#define DRM_PROC_ENTRIES ARRAY_SIZE(drm_proc_list)
 
 /**
  * Initialize the DRI proc filesystem for a device.


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] w1: Use ARRAY_SIZE macro when appropriate
    2007-02-06 16:08 99% ` [PATCH 2.6.20] reiserfs: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
@ 2007-02-06 16:09 99% ` Ahmed S. Darwish
  2007-02-06 16:08 99% ` [PATCH 2.6.20] rcutorture: " Ahmed S. Darwish
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:09 UTC (permalink / raw)
  To: johnpol; +Cc: linux-kernel

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index b022fff..732db47 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -141,7 +141,7 @@ static inline int w1_convert_temp(u8 rom[9], u8 fid)
 {
 	int i;
 
-	for (i=0; i<sizeof(w1_therm_families)/sizeof(w1_therm_families[0]); ++i)
+	for (i = 0; i < ARRAY_SIZE(w1_therm_families); ++i)
 		if (w1_therm_families[i].f->fid == fid)
 			return w1_therm_families[i].convert(rom);
 
@@ -238,7 +238,7 @@ static int __init w1_therm_init(void)
 {
 	int err, i;
 
-	for (i=0; i<sizeof(w1_therm_families)/sizeof(w1_therm_families[0]); ++i) {
+	for (i = 0; i < ARRAY_SIZE(w1_therm_families); ++i) {
 		err = w1_register_family(w1_therm_families[i].f);
 		if (err)
 			w1_therm_families[i].broken = 1;
@@ -251,7 +251,7 @@ static void __exit w1_therm_fini(void)
 {
 	int i;
 
-	for (i=0; i<sizeof(w1_therm_families)/sizeof(w1_therm_families[0]); ++i)
+	for (i = 0; i < ARRAY_SIZE(w1_therm_families); ++i)
 		if (!w1_therm_families[i].broken)
 			w1_unregister_family(w1_therm_families[i].f);
 }


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] toshiba-acpi: Use ARRAY_SIZE macro when appropriate
                     ` (6 preceding siblings ...)
  2007-02-06 16:07 99% ` [PATCH 2.6.20] s390-drivers: " Ahmed S. Darwish
@ 2007-02-06 16:09 99% ` Ahmed S. Darwish
  2007-02-06 16:06 99% ` [PATCH 2.6.20] drivers/md.c: " Ahmed S. Darwish
  2007-02-06 16:10 99% ` [PATCH 2.6.20] drm: " Ahmed S. Darwish
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:09 UTC (permalink / raw)
  To: toshiba_acpi; +Cc: linux-kernel

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/acpi/toshiba_acpi.c b/drivers/acpi/toshiba_acpi.c
index d9b651f..0208d3a 100644
--- a/drivers/acpi/toshiba_acpi.c
+++ b/drivers/acpi/toshiba_acpi.c
@@ -125,7 +125,7 @@ static int write_acpi_int(const char *methodName, int val)
 	union acpi_object in_objs[1];
 	acpi_status status;
 
-	params.count = sizeof(in_objs) / sizeof(in_objs[0]);
+	params.count = ARRAY_SIZE(in_objs);
 	params.pointer = in_objs;
 	in_objs[0].type = ACPI_TYPE_INTEGER;
 	in_objs[0].integer.value = val;

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] reiserfs: Use ARRAY_SIZE macro when appropriate
  @ 2007-02-06 16:08 99% ` Ahmed S. Darwish
  2007-02-06 16:09 99% ` [PATCH 2.6.20] w1: " Ahmed S. Darwish
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:08 UTC (permalink / raw)
  To: reiserfs-dev; +Cc: linux-kernel, reiserfs-list

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/fs/reiserfs/do_balan.c b/fs/reiserfs/do_balan.c
index fba304e..f85c5cf 100644
--- a/fs/reiserfs/do_balan.c
+++ b/fs/reiserfs/do_balan.c
@@ -19,6 +19,7 @@
 #include <linux/time.h>
 #include <linux/reiserfs_fs.h>
 #include <linux/buffer_head.h>
+#include <linux/kernel.h>
 
 #ifdef CONFIG_REISERFS_CHECK
 
@@ -1756,7 +1757,7 @@ static void store_thrown(struct tree_balance *tb, struct buffer_head *bh)
 	if (buffer_dirty(bh))
 		reiserfs_warning(tb->tb_sb,
 				 "store_thrown deals with dirty buffer");
-	for (i = 0; i < sizeof(tb->thrown) / sizeof(tb->thrown[0]); i++)
+	for (i = 0; i < ARRAY_SIZE(tb->thrown); i++)
 		if (!tb->thrown[i]) {
 			tb->thrown[i] = bh;
 			get_bh(bh);	/* free_thrown puts this */
@@ -1769,7 +1770,7 @@ static void free_thrown(struct tree_balance *tb)
 {
 	int i;
 	b_blocknr_t blocknr;
-	for (i = 0; i < sizeof(tb->thrown) / sizeof(tb->thrown[0]); i++) {
+	for (i = 0; i < ARRAY_SIZE(tb->thrown); i++) {
 		if (tb->thrown[i]) {
 			blocknr = tb->thrown[i]->b_blocknr;
 			if (buffer_dirty(tb->thrown[i]))


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] intel-agp: Use ARRAY_SIZE macro when appropriate
                     ` (4 preceding siblings ...)
  2007-02-06 16:04 99% ` [PATCH 2.6.20] isdn-capi: " Ahmed S. Darwish
@ 2007-02-06 16:08 99% ` Ahmed S. Darwish
  2007-02-06 16:07 99% ` [PATCH 2.6.20] s390-drivers: " Ahmed S. Darwish
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:08 UTC (permalink / raw)
  To: davej; +Cc: linux-kernel

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index ab0a9c0..7233310 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -5,6 +5,7 @@
 #include <linux/module.h>
 #include <linux/pci.h>
 #include <linux/init.h>
+#include <linux/kernel.h>
 #include <linux/pagemap.h>
 #include <linux/agp_backend.h>
 #include "agp.h"
@@ -803,7 +804,7 @@ static int intel_i915_remove_entries(struct agp_memory *mem,off_t pg_start,
  */
 static int intel_i9xx_fetch_size(void)
 {
-	int num_sizes = sizeof(intel_i830_sizes) / sizeof(*intel_i830_sizes);
+	int num_sizes = ARRAY_SIZE(intel_i830_sizes);
 	int aper_size; /* size in megabytes */
 	int i;
 


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] rcutorture: Use ARRAY_SIZE macro when appropriate
    2007-02-06 16:08 99% ` [PATCH 2.6.20] reiserfs: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
  2007-02-06 16:09 99% ` [PATCH 2.6.20] w1: " Ahmed S. Darwish
@ 2007-02-06 16:08 99% ` Ahmed S. Darwish
  2007-02-06 16:07 99% ` [PATCH 2.6.20] infinband: " Ahmed S. Darwish
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:08 UTC (permalink / raw)
  To: josh; +Cc: linux-kernel

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
index 482b11f..97c2277 100644
--- a/kernel/rcutorture.c
+++ b/kernel/rcutorture.c
@@ -899,7 +899,7 @@ rcu_torture_init(void)
 	/* Set up the freelist. */
 
 	INIT_LIST_HEAD(&rcu_torture_freelist);
-	for (i = 0; i < sizeof(rcu_tortures) / sizeof(rcu_tortures[0]); i++) {
+	for (i = 0; i < ARRAY_SIZE(rcu_tortures); i++) {
 		rcu_tortures[i].rtort_mbtest = 0;
 		list_add_tail(&rcu_tortures[i].rtort_free,
 			      &rcu_torture_freelist);


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] s390-drivers: Use ARRAY_SIZE macro when appropriate
                     ` (5 preceding siblings ...)
  2007-02-06 16:08 99% ` [PATCH 2.6.20] intel-agp: " Ahmed S. Darwish
@ 2007-02-06 16:07 99% ` Ahmed S. Darwish
  2007-02-06 16:09 99% ` [PATCH 2.6.20] toshiba-acpi: " Ahmed S. Darwish
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:07 UTC (permalink / raw)
  To: schwidefsky; +Cc: linux-kernel, linux-390

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
Not compile tested due to (ofcourse ;)) missing hardware.

diff --git a/drivers/s390/cio/device_id.c b/drivers/s390/cio/device_id.c
index f172759..997f468 100644
--- a/drivers/s390/cio/device_id.c
+++ b/drivers/s390/cio/device_id.c
@@ -11,6 +11,7 @@
 
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/kernel.h>
 
 #include <asm/ccwdev.h>
 #include <asm/delay.h>
@@ -138,7 +139,7 @@ VM_virtual_device_info (__u16 devno, struct senseid *ps)
 		ps->cu_model = 0x60;
 		return;
 	}
-	for (i = 0; i < sizeof(vm_devices) / sizeof(vm_devices[0]); i++)
+	for (i = 0; i < ARRAY_SIZE(vm_devices); i++)
 		if (diag_data.vrdcvcla == vm_devices[i].vrdcvcla &&
 		    diag_data.vrdcvtyp == vm_devices[i].vrdcvtyp) {
 			ps->cu_type = vm_devices[i].cu_type;


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] infinband: Use ARRAY_SIZE macro when appropriate
                     ` (2 preceding siblings ...)
  2007-02-06 16:08 99% ` [PATCH 2.6.20] rcutorture: " Ahmed S. Darwish
@ 2007-02-06 16:07 99% ` Ahmed S. Darwish
  2007-02-06 16:04 99% ` [PATCH 2.6.20] isdn-capi: " Ahmed S. Darwish
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:07 UTC (permalink / raw)
  To: rolandd; +Cc: linux-kernel, openib-general

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index 63d2a39..7fabb42 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -36,6 +36,7 @@
 #include <linux/module.h>
 #include <linux/string.h>
 #include <linux/errno.h>
+#include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/init.h>
 #include <linux/mutex.h>
@@ -93,7 +94,7 @@ static int ib_device_check_mandatory(struct ib_device *device)
 	};
 	int i;
 
-	for (i = 0; i < sizeof mandatory_table / sizeof mandatory_table[0]; ++i) {
+	for (i = 0; i < ARRAY_SIZE(mandatory_table); ++i) {
 		if (!*(void **) ((void *) device + mandatory_table[i].offset)) {
 			printk(KERN_WARNING "Device %s is missing mandatory function %s\n",
 			       device->name, mandatory_table[i].name);

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] drivers/md.c: Use ARRAY_SIZE macro when appropriate
                     ` (7 preceding siblings ...)
  2007-02-06 16:09 99% ` [PATCH 2.6.20] toshiba-acpi: " Ahmed S. Darwish
@ 2007-02-06 16:06 99% ` Ahmed S. Darwish
  2007-02-06 16:10 99% ` [PATCH 2.6.20] drm: " Ahmed S. Darwish
  9 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:06 UTC (permalink / raw)
  To: mingo; +Cc: linux-kernel, linux-raid

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/md/md.c b/drivers/md/md.c
index e8807ea..6f6d9e5 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -33,6 +33,7 @@
 */
 
 #include <linux/module.h>
+#include <linux/kernel.h>
 #include <linux/kthread.h>
 #include <linux/linkage.h>
 #include <linux/raid/md.h>
@@ -2635,8 +2636,7 @@ metadata_store(mddev_t *mddev, const char *buf, size_t len)
 	minor = simple_strtoul(buf, &e, 10);
 	if (e==buf || (*e && *e != '\n') )
 		return -EINVAL;
-	if (major >= sizeof(super_types)/sizeof(super_types[0]) ||
-	    super_types[major].name == NULL)
+	if (major >= ARRAY_SIZE(super_types) || super_types[major].name == NULL)
 		return -ENOENT;
 	mddev->major_version = major;
 	mddev->minor_version = minor;
@@ -3973,7 +3973,7 @@ static int set_array_info(mddev_t * mddev, mdu_array_info_t *info)
 	if (info->raid_disks == 0) {
 		/* just setting version number for superblock loading */
 		if (info->major_version < 0 ||
-		    info->major_version >= sizeof(super_types)/sizeof(super_types[0]) ||
+		    info->major_version >= ARRAY_SIZE(super_types) ||
 		    super_types[info->major_version].name == NULL) {
 			/* maybe try to auto-load a module? */
 			printk(KERN_INFO 


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] isdn-capi: Use ARRAY_SIZE macro when appropriate
                     ` (3 preceding siblings ...)
  2007-02-06 16:07 99% ` [PATCH 2.6.20] infinband: " Ahmed S. Darwish
@ 2007-02-06 16:04 99% ` Ahmed S. Darwish
    2007-02-06 16:08 99% ` [PATCH 2.6.20] intel-agp: " Ahmed S. Darwish
                   ` (4 subsequent siblings)
  9 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 16:04 UTC (permalink / raw)
  To: kkeil, kai.germaschewski; +Cc: linux-kernel, isdn4linux

Hi all,

A patch to use ARRAY_SIZE macro already defined in kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
 capi.c    |    4 ++--
 capidrv.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
index d22c022..3804591 100644
--- a/drivers/isdn/capi/capi.c
+++ b/drivers/isdn/capi/capi.c
@@ -1456,7 +1456,7 @@ static struct procfsentries {
 
 static void __init proc_init(void)
 {
-    int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
+    int nelem = ARRAY_SIZE(procfsentries);
     int i;
 
     for (i=0; i < nelem; i++) {
@@ -1468,7 +1468,7 @@ static void __init proc_init(void)
 
 static void __exit proc_exit(void)
 {
-    int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
+    int nelem = ARRAY_SIZE(procfsentries);
     int i;
 
     for (i=nelem-1; i >= 0; i--) {
diff --git a/drivers/isdn/capi/capidrv.c b/drivers/isdn/capi/capidrv.c
index c4d438c..8cec9c3 100644
--- a/drivers/isdn/capi/capidrv.c
+++ b/drivers/isdn/capi/capidrv.c
@@ -2218,7 +2218,7 @@ static struct procfsentries {
 
 static void __init proc_init(void)
 {
-    int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
+    int nelem = ARRAY_SIZE(procfsentries);
     int i;
 
     for (i=0; i < nelem; i++) {
@@ -2230,7 +2230,7 @@ static void __init proc_init(void)
 
 static void __exit proc_exit(void)
 {
-    int nelem = sizeof(procfsentries)/sizeof(procfsentries[0]);
+    int nelem = ARRAY_SIZE(procfsentries);
     int i;
 
     for (i=nelem-1; i >= 0; i--) {

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
  @ 2007-02-06 10:00 99%       ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06 10:00 UTC (permalink / raw)
  To: Auke Kok; +Cc: Alexey Dobriyan, jeffrey.t.kirsher, linux-kernel, netdev

On Mon, Feb 05, 2007 at 12:31:26PM -0800, Auke Kok wrote:
> Alexey Dobriyan wrote:
> >On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
> >>A patch to use ARRAY_SIZE macro already defined in kernel.h.
> >
> >Remove it and use ARRAY_SIZE instead.
> >
> >>--- a/drivers/net/ixgb/ixgb_param.c
> >>+++ b/drivers/net/ixgb/ixgb_param.c
> >>@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option 
> >>*opt)
> >> 	return -1;
> >> }
> >> 
> >>-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
> >>+#define LIST_LEN(l) ARRAY_SIZE(l)
> 
> yes, well spotted. Please change line 338 in this file to read:
> 
>      .arg  = { .l = { .nr = ARRAY_SIZE(fc_list),
> 
> instead, so you can remove the LIST_LEN macro completely.
 
Thanks, Here's the new patch.

Use ARRAY_SIZE macro when appropriate.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..c38ce73 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,8 +245,6 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
 	return -1;
 }
 
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
-
 /**
  * ixgb_check_options - Range Checking for Command Line Parameters
  * @adapter: board private structure
@@ -335,7 +333,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
 			.name = "Flow Control",
 			.err  = "reading default settings from EEPROM",
 			.def  = ixgb_fc_tx_pause,
-			.arg  = { .l = { .nr = LIST_LEN(fc_list),
+			.arg  = { .l = { .nr = ARRAY_SIZE(fc_list),
 					 .p = fc_list }}
 		};


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 2.6.20] ibm_emac: Use ARRAY_SIZE macro when appropriate
  @ 2007-02-06  9:12 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-06  9:12 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: ebs, linux-kernel, netdev, linuxppc-embedded

On Mon, Feb 05, 2007 at 11:22:06PM +0300, Alexey Dobriyan wrote:
> On Mon, Feb 05, 2007 at 06:59:16PM +0200, Ahmed S. Darwish wrote:
> > A patch to use ARRAY_SIZE macro already defined in kernel.h.
> 
> OK, but checks you're changing are strange. idx there is signed so
> 
> 	BUG_ON(idx < 0 || idx > ARRAY_SIZE());
> 
> should be more appropriate.

It's just a janitor patch. I don't like to mess with code logic in such
kind of patches (to minimize errors and because I can't find time to
understand all affected files since they are scattered allover the tree).

Thanks,
-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] wavelan: Use ARRAY_SIZE macro when appropriate
  2007-02-05 16:54 99% [PATCH 00] A series of patches to use ARRAY_SIZE in `net' drivers Ahmed S. Darwish
  2007-02-05 16:59 99% ` [PATCH 2.6.20] ibm_emac: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
@ 2007-02-05 17:00 99% ` Ahmed S. Darwish
  2007-02-05 16:59 99% ` [PATCH 2.6.20] ixgb: " Ahmed S. Darwish
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-05 17:00 UTC (permalink / raw)
  To: jt, linville; +Cc: linux-kernel, netdev

Hi,

A trivial patch to use ARRAY_SIZE macro.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/net/wireless/wavelan.p.h b/drivers/net/wireless/wavelan.p.h
index 72b646c..fe12c77 100644
--- a/drivers/net/wireless/wavelan.p.h
+++ b/drivers/net/wireless/wavelan.p.h
@@ -450,7 +450,7 @@ static const char	*version	= "wavelan.c : v24 (SMP + wireless extensions) 11/12/
 #define	WATCHDOG_JIFFIES	(512*HZ/100)
 
 /* Macro to get the number of elements in an array */
-#define	NELS(a)				(sizeof(a) / sizeof(a[0]))
+#define	NELS(a)				ARRAY_SIZE(a)
 
 /* ------------------------ PRIVATE IOCTL ------------------------ */
 



-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
  2007-02-05 16:54 99% [PATCH 00] A series of patches to use ARRAY_SIZE in `net' drivers Ahmed S. Darwish
  2007-02-05 16:59 99% ` [PATCH 2.6.20] ibm_emac: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
  2007-02-05 17:00 99% ` [PATCH 2.6.20] wavelan: " Ahmed S. Darwish
@ 2007-02-05 16:59 99% ` Ahmed S. Darwish
    2007-02-05 16:58 99% ` [PATCH 2.6.20] hostap: " Ahmed S. Darwish
  2007-02-05 16:55 99% ` [PATCH 2.6.20] e1000: " Ahmed S. Darwish
  4 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-02-05 16:59 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: linux-kernel, netdev

Hi,

A patch to use ARRAY_SIZE macro already defined in kernel.h.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..26031fe 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
 	return -1;
 }
 
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
+#define LIST_LEN(l) ARRAY_SIZE(l)
 
 /**
  * ixgb_check_options - Range Checking for Command Line Parameters


-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] ibm_emac: Use ARRAY_SIZE macro when appropriate
  2007-02-05 16:54 99% [PATCH 00] A series of patches to use ARRAY_SIZE in `net' drivers Ahmed S. Darwish
@ 2007-02-05 16:59 99% ` Ahmed S. Darwish
    2007-02-05 17:00 99% ` [PATCH 2.6.20] wavelan: " Ahmed S. Darwish
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-02-05 16:59 UTC (permalink / raw)
  To: ebs; +Cc: linux-kernel, netdev, linuxppc-embedded

Hi,

A patch to use ARRAY_SIZE macro already defined in kernel.h.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
Patch isn't compile-tested cause I don't have the needed hardware.

diff --git a/drivers/net/ibm_emac/ibm_emac_debug.c b/drivers/net/ibm_emac/ibm_emac_debug.c
index 92f970d..1f70906 100644
--- a/drivers/net/ibm_emac/ibm_emac_debug.c
+++ b/drivers/net/ibm_emac/ibm_emac_debug.c
@@ -132,7 +132,7 @@ void emac_dbg_register(int idx, struct ocp_enet_private *dev)
 {
 	unsigned long flags;
 
-	if (idx >= sizeof(__emacs) / sizeof(__emacs[0])) {
+	if (idx >= ARRAY_SIZE(__emacs)) {
 		printk(KERN_WARNING
 		       "invalid index %d when registering EMAC for debugging\n",
 		       idx);
@@ -148,7 +148,7 @@ void mal_dbg_register(int idx, struct ibm_ocp_mal *mal)
 {
 	unsigned long flags;
 
-	if (idx >= sizeof(__mals) / sizeof(__mals[0])) {
+	if (idx >= ARRAY_SIZE(__mals)) {
 		printk(KERN_WARNING
 		       "invalid index %d when registering MAL for debugging\n",
 		       idx);
@@ -167,11 +167,11 @@ void emac_dbg_dump_all(void)
 
 	local_irq_save(flags);
 
-	for (i = 0; i < sizeof(__mals) / sizeof(__mals[0]); ++i)
+	for (i = 0; i < ARRAY_SIZE(__mals); ++i)
 		if (__mals[i])
 			emac_mal_dump(__mals[i]);
 
-	for (i = 0; i < sizeof(__emacs) / sizeof(__emacs[0]); ++i)
+	for (i = 0; i < ARRAY_SIZE(__emacs); ++i)
 		if (__emacs[i])
 			emac_mac_dump(i, __emacs[i]);
 

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] hostap: Use ARRAY_SIZE macro when appropriate
  2007-02-05 16:54 99% [PATCH 00] A series of patches to use ARRAY_SIZE in `net' drivers Ahmed S. Darwish
                   ` (2 preceding siblings ...)
  2007-02-05 16:59 99% ` [PATCH 2.6.20] ixgb: " Ahmed S. Darwish
@ 2007-02-05 16:58 99% ` Ahmed S. Darwish
  2007-02-05 16:55 99% ` [PATCH 2.6.20] e1000: " Ahmed S. Darwish
  4 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-05 16:58 UTC (permalink / raw)
  To: jkmaline, linville; +Cc: linux-kernel, netdev

Hi,

A patch to use ARRAY_SIZE macro in the Host AP wireless driver.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
Patch is compile tested.

diff --git a/drivers/net/wireless/hostap/hostap.h b/drivers/net/wireless/hostap/hostap.h
index e89c890..ef37a75 100644
--- a/drivers/net/wireless/hostap/hostap.h
+++ b/drivers/net/wireless/hostap/hostap.h
@@ -2,13 +2,14 @@
 #define HOSTAP_H
 
 #include <linux/ethtool.h>
+#include <linux/kernel.h>
 
 #include "hostap_wlan.h"
 #include "hostap_ap.h"
 
 static const long freq_list[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442,
 				  2447, 2452, 2457, 2462, 2467, 2472, 2484 };
-#define FREQ_COUNT (sizeof(freq_list) / sizeof(freq_list[0]))
+#define FREQ_COUNT ARRAY_SIZE(freq_list)
 
 /* hostap.c */
 

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] e1000: Use ARRAY_SIZE macro when appropriate
  2007-02-05 16:54 99% [PATCH 00] A series of patches to use ARRAY_SIZE in `net' drivers Ahmed S. Darwish
                   ` (3 preceding siblings ...)
  2007-02-05 16:58 99% ` [PATCH 2.6.20] hostap: " Ahmed S. Darwish
@ 2007-02-05 16:55 99% ` Ahmed S. Darwish
  4 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-05 16:55 UTC (permalink / raw)
  To: cramerj, john.ronciak; +Cc: linux-kernel, netdev

Hi,

A patch to use ARRAY_SIZE macro already defined in kernel.h.

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
Patch is compile tested.

diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index fb96c87..d21706e 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -746,7 +746,7 @@ err_setup:
 	uint32_t pat, value;                                                   \
 	uint32_t test[] =                                                      \
 		{0x5A5A5A5A, 0xA5A5A5A5, 0x00000000, 0xFFFFFFFF};              \
-	for (pat = 0; pat < sizeof(test)/sizeof(test[0]); pat++) {              \
+	for (pat = 0; pat < ARRAY_SIZE(test); pat++) {              \
 		E1000_WRITE_REG(&adapter->hw, R, (test[pat] & W));             \
 		value = E1000_READ_REG(&adapter->hw, R);                       \
 		if (value != (test[pat] & W & M)) {                             \

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 00] A series of patches to use ARRAY_SIZE in `net' drivers
@ 2007-02-05 16:54 99% Ahmed S. Darwish
  2007-02-05 16:59 99% ` [PATCH 2.6.20] ibm_emac: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
                   ` (4 more replies)
  0 siblings, 5 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-05 16:54 UTC (permalink / raw)
  To: linux-kernel, netdev

Hi all,

Follows is a sereis of patches to use ARRAY_SIZE macro in drivers/net. 
Patches are sent separately according to their maintaners as replies to 
this thread.

 apne.c                     |    2 +-
 arm/am79c961a.c            |    2 +-
 atarilance.c               |    2 +-
 cs89x0.c                   |    6 +++---
 e1000/e1000_ethtool.c      |    2 +-
 fec_8xx/fec_mii.c          |    4 ++--
 ibm_emac/ibm_emac_debug.c  |    8 ++++----
 irda/actisys-sir.c         |    3 ++-
 ixgb/ixgb_param.c          |    2 +-
 lp486e.c                   |    2 +-
 ne-h8300.c                 |    2 +-
 ne.c                       |    2 +-
 ne2.c                      |    2 +-
 ne2k-pci.c                 |    2 +-
 netxen/netxen_nic_hw.c     |    2 +-
 pcmcia/axnet_cs.c          |    2 +-
 pcmcia/pcnet_cs.c          |    2 +-
 sk98lin/skgemib.c          |    4 +++-
 sk98lin/skgesirq.c         |    3 ++-
 skfp/smt.c                 |    3 ++-
 skfp/srf.c                 |    6 ++++--
 wireless/airo.c            |    4 ++--
 wireless/hostap/hostap.h   |    3 ++-
 wireless/ipw2100.c         |   14 ++++++--------
 wireless/prism54/oid_mgt.c |    4 +++-
 wireless/wavelan.p.h       |    2 +-
 zorro8390.c                |    2 +-
 27 files changed, 50 insertions(+), 42 deletions(-)

Thanks,
-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 00] A series of patches to use ARRAY_SIZE under video subtree
@ 2007-02-05 16:51 99% Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-05 16:51 UTC (permalink / raw)
  To: linux-kernel, video4linux-list

Hi all,

Follows is a series of patches to use ARRAY_SIZE macro in the video drivers
located under /drivers/media/video.
Patches are test compiled and can be applied cleanly on 2.6.20

 cpia2/cpia2_v4l.c             |    9 +++++----
 ov7670.c                      |    7 ++++---
 pvrusb2/pvrusb2-audio.c       |   10 ++++------
 pvrusb2/pvrusb2-ctrl.c        |    4 ++--
 pvrusb2/pvrusb2-cx2584x-v4l.c |   10 ++++------
 pvrusb2/pvrusb2-debugifc.c    |    5 +++--
 pvrusb2/pvrusb2-eeprom.c      |    3 ++-
 pvrusb2/pvrusb2-hdw.c         |    3 ++-
 tveeprom.c                    |    6 +++---
 tvp5150.c                     |    3 ++-
 usbvideo/quickcam_messenger.c |    2 +-
 11 files changed, 32 insertions(+), 30 deletions(-)

Thanks,
-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] arch ARM: Use ARRAY_SIZE macro when appropriate
    2007-02-05  2:41 99% ` [PATCH 2.6.20] arch AVR32: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
  2007-02-05  2:40 99% ` [PATCH 2.6.20] arch CRIS: user " Ahmed S. Darwish
@ 2007-02-05  2:43 99% ` Ahmed S. Darwish
  2 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-05  2:43 UTC (permalink / raw)
  To: spyro, kernel; +Cc: linux-kernel

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
Patch isn't compile checked cause I have no ARM machine at hand.
Thanks,

diff --git a/arch/arm/kernel/ecard.c b/arch/arm/kernel/ecard.c
index 71257e3..f1c0fb9 100644
--- a/arch/arm/kernel/ecard.c
+++ b/arch/arm/kernel/ecard.c
@@ -1009,7 +1009,7 @@ ecard_probe(int slot, card_type_t type)
 		ec->fiqmask = 4;
 	}
 
-	for (i = 0; i < sizeof(blacklist) / sizeof(*blacklist); i++)
+	for (i = 0; i < ARRAY_SIZE(blacklist); i++)
 		if (blacklist[i].manufacturer == ec->cid.manufacturer &&
 		    blacklist[i].product == ec->cid.product) {
 			ec->card_desc = blacklist[i].type;
diff --git a/arch/arm26/kernel/ecard.c b/arch/arm26/kernel/ecard.c
index 9dbc172..e2bcefc 100644
--- a/arch/arm26/kernel/ecard.c
+++ b/arch/arm26/kernel/ecard.c
@@ -665,7 +665,7 @@ ecard_probe(int slot, card_type_t type)
 		ec->fiqmask = 4;
 	}
 
-	for (i = 0; i < sizeof(blacklist) / sizeof(*blacklist); i++)
+	for (i = 0; i < ARRAY_SIZE(blacklist); i++)
 		if (blacklist[i].manufacturer == ec->cid.manufacturer &&
 		    blacklist[i].product == ec->cid.product) {
 			ec->card_desc = blacklist[i].type;

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] arch AVR32: Use ARRAY_SIZE macro when appropriate
  @ 2007-02-05  2:41 99% ` Ahmed S. Darwish
  2007-02-05  2:40 99% ` [PATCH 2.6.20] arch CRIS: user " Ahmed S. Darwish
  2007-02-05  2:43 99% ` [PATCH 2.6.20] arch ARM: Use " Ahmed S. Darwish
  2 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-05  2:41 UTC (permalink / raw)
  To: hskinnemoen; +Cc: linux-kernel

Hi Haavard,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
Patch isn't compile checked cause I have no AVR32 machine at hand.
Thanks,

diff --git a/arch/avr32/kernel/setup.c b/arch/avr32/kernel/setup.c
index a342116..c6734ae 100644
--- a/arch/avr32/kernel/setup.c
+++ b/arch/avr32/kernel/setup.c
@@ -16,6 +16,7 @@
 #include <linux/module.h>
 #include <linux/root_dev.h>
 #include <linux/cpu.h>
+#include <linux/kernel.h>
 
 #include <asm/sections.h>
 #include <asm/processor.h>
@@ -174,8 +175,7 @@ static int __init parse_tag_mem_range(struct tag *tag,
 	 * Copy the data so the bootmem init code doesn't need to care
 	 * about it.
 	 */
-	if (mem_range_next_free >=
-	    (sizeof(mem_range_cache) / sizeof(mem_range_cache[0])))
+	if (mem_range_next_free >= ARRAY_SIZE(mem_range_cache))
 		panic("Physical memory map too complex!\n");
 
 	new = &mem_range_cache[mem_range_next_free++];

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* [PATCH 2.6.20] arch CRIS: user ARRAY_SIZE macro when appropriate
    2007-02-05  2:41 99% ` [PATCH 2.6.20] arch AVR32: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
@ 2007-02-05  2:40 99% ` Ahmed S. Darwish
  2007-02-05  2:43 99% ` [PATCH 2.6.20] arch ARM: Use " Ahmed S. Darwish
  2 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-05  2:40 UTC (permalink / raw)
  To: starvik; +Cc: linux-kernel

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
---
Patch isn't compile checked since I have no CRIS machine at hand.

diff --git a/arch/cris/arch-v10/drivers/axisflashmap.c b/arch/cris/arch-v10/drivers/axisflashmap.c
index ffade19..c5d90fc 100644
--- a/arch/cris/arch-v10/drivers/axisflashmap.c
+++ b/arch/cris/arch-v10/drivers/axisflashmap.c
@@ -359,8 +359,7 @@ static struct mtd_info *flash_probe(void)
 		 * So we use the MTD concatenation layer instead of further
 		 * complicating the probing procedure.
 		 */
-		mtd_cse = mtd_concat_create(mtds,
-					    sizeof(mtds) / sizeof(mtds[0]),
+		mtd_cse = mtd_concat_create(mtds, ARRAY_SIZE(mtds), 
 					    "cse0+cse1");
 #else
 		printk(KERN_ERR "%s and %s: Cannot concatenate due to kernel "
diff --git a/arch/cris/mm/tlb.c b/arch/cris/mm/tlb.c
index 0df390a..c4a98e2 100644
--- a/arch/cris/mm/tlb.c
+++ b/arch/cris/mm/tlb.c
@@ -8,6 +8,7 @@
  */
 
 #include <linux/init.h>
+#include <linux/kernel.h>
 #include <asm/tlb.h>
 
 #define D(x)
@@ -100,7 +101,7 @@ tlb_init(void)
 
 	/* clear the page_id map */
 
-	for (i = 1; i < sizeof (page_id_map) / sizeof (page_id_map[0]); i++)
+	for (i = 1; i < ARRAY_SIZE(page_id_map); i++)
 		page_id_map[i] = NULL;
 	
 	/* invalidate the entire TLB */

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: A CodingStyle suggestion
  2007-02-03 21:58 99% A CodingStyle suggestion Ahmed S. Darwish
@ 2007-02-04 12:10 99% ` Ahmed S. Darwish
    1 sibling, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-04 12:10 UTC (permalink / raw)
  To: linux-kernel

On Sat, Feb 03, 2007 at 11:58:48PM +0200, Darwish wrote:
> Hi all,
> 
> In CodingStyle Chapter 16 "Function return value and names", why not
> adding a comment about the favorable community way of checking the return
> value. ie:
> 
> ret = do_method();
> if (ret) {
>    /* deal with error */
> }

Thanks for all the replies, A patch will be sent in a new thread.  

Regards
-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: A CodingStyle suggestion
  @ 2007-02-04  0:05 99%   ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-04  0:05 UTC (permalink / raw)
  To: Richard Knutsson; +Cc: linux-kernel, randy.dunlap

On Sat, Feb 03, 2007 at 11:56:16PM +0100, Richard Knutsson wrote:
> Ahmed S. Darwish wrote:
> >Hi all,
> >
> >In CodingStyle Chapter 16 "Function return value and names", why not
> >adding a comment about the favorable community way of checking the return
> >value. ie:
> >
> >ret = do_method();
> >if (ret) {
> >   /* deal with error */
> >}
> >
> >and not other ways like:
> >
> >if (do_method()) or 
> So:
> 
> if (is_true()) {
> 	/* do something */
> }
> 
> is alright then? If so, I agree, but please make it real clear in the 
> document ;)

Good catch :). A small grep of `access_ok' reveals that it's always used in the 
form of:
if (!access_ok()) { .. }

I can conclude that verbal/imperative methods like `kmalloc, add_work' be 
checked as:
ret = do_work();
if (ret) { ... }
and predicate methods like `acess_ok, pci_dev_present' be checked like:
if (!access_ok) { ... }
if (pci_dev_present) { ...}

Any comments ?

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* A CodingStyle suggestion
@ 2007-02-03 21:58 99% Ahmed S. Darwish
  2007-02-04 12:10 99% ` Ahmed S. Darwish
    0 siblings, 2 replies; 200+ results
From: Ahmed S. Darwish @ 2007-02-03 21:58 UTC (permalink / raw)
  To: linux-kernel

Hi all,

In CodingStyle Chapter 16 "Function return value and names", why not
adding a comment about the favorable community way of checking the return
value. ie:

ret = do_method();
if (ret) {
   /* deal with error */
}

and not other ways like:

if (do_method()) or if ((ret = do_method()) > value) ...

A patch is ready if the replies are positive.

Thanks,
-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: after effects of a kernel API change
  @ 2007-01-18  9:44 99%     ` Ahmed S. Darwish
  0 siblings, 0 replies; 200+ results
From: Ahmed S. Darwish @ 2007-01-18  9:44 UTC (permalink / raw)
  To: Rajat Jain; +Cc: Daniel Rodrick, kernelnewbies, Linux Newbie, linux-kernel

On Thu, Jan 18, 2007 at 11:05:53AM +0530, Rajat Jain wrote:
> >>
> >> Is there any way volunteers like me can help in this exercise?
> >
> >See the /APIchanges in the Kernel Janitors TODO list
> >http://kernelnewbies.org/KernelJanitors/Todo
> >
> [...]
> 1) How do I make sure if some one is NOT working on any of the
> mentioned bullet points? Who coordinates? On what mailing list?

Check latest trees to make sure the work is not duplicated. espicially 
trees like -mm and subsystem ones.

> 2) Do any patches for the above Todo list have the chances of getting
> merged into the mainstream kernel? Who approves? I suppose the
> respective maintainer of the driver / subsystem getting affected?

I advise lurking (following/reading) the list for at least 2 or 3 weeks and 
you'll automatically understand how the "system" works. Also check:

$KERNEL_TREE/Documentation/HOWTO
$KERNEL_TREE/Documentation/SubmittingPatches
$KERNEL_TREE/Documentation/CodingStyle

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

* Re: after effects of a kernel API change
  @ 2007-01-18  5:10 99% ` Ahmed S. Darwish
    0 siblings, 1 reply; 200+ results
From: Ahmed S. Darwish @ 2007-01-18  5:10 UTC (permalink / raw)
  To: Daniel Rodrick; +Cc: kernelnewbies, Linux Newbie, linux-kernel

On Thu, Jan 18, 2007 at 09:45:04AM +0530, Daniel Rodrick wrote:
> Hi list,
> 
> Whenever there is a change in the kernel API (or a new API is
> introduced), all of the drivers that use the older API need to be
> changed (or recommended to be changed). I believe it is the
> responsibility of the person changing the kernel API, to change all
> the drivers that have found their way into the kernel code?
> 
> How does this happen? Because the person who brought the change in the
> API might not know the internals of all the drivers?
> 
> Is there any way volunteers like me can help in this exercise?

See the /APIchanges in the Kernel Janitors TODO list
http://kernelnewbies.org/KernelJanitors/Todo

Also: Documentation/stable_api_nonsense.txt

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com

^ permalink raw reply	[relevance 99%]

Results 1-200 of 424 (estimated)   | reverse results
     [not found]     <45E6BF26.7080607@bristyle.com>
     [not found]     ` <45E73715.9030909@qualcomm.com>
2007-03-24  8:56       ` PATCH: tun/tap driver hw address handling Brian Braunstein
2007-03-24 17:04 99%     ` Ahmed S. Darwish
     [not found]     <0-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com>
     [not found]     ` <2-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com>
2020-11-12  7:41 99%   ` [PATCH v4 2/2] mm: prevent gup_fast from racing with COW during fork Ahmed S. Darwish
2007-02-03 21:58 99% A CodingStyle suggestion Ahmed S. Darwish
2007-02-04 12:10 99% ` Ahmed S. Darwish
2007-02-03 22:56     ` Richard Knutsson
2007-02-04  0:05 99%   ` Ahmed S. Darwish
2007-03-26 19:14 99% [PATCH] IRQ: Check for PERCPU flag only when adding first irqaction Ahmed S. Darwish
2007-03-27  8:54 99% ` Ahmed S. Darwish
2007-10-24 11:00 99% Rule parsing from a virtual FS write() syscall Ahmed S. Darwish
2019-03-10 20:03 99% [PATCH] printk: kmsg_dump: Mark registered flag as private Ahmed S. Darwish
2019-03-11 12:49     ` Sergey Senozhatsky
2019-03-12 20:05 99%   ` Ahmed S. Darwish
2008-02-19 15:37 99% [PATCH] Tasklets: Avoid duplicating __tasklet_{,hi_}schedule() code Ahmed S. Darwish
2008-02-19 15:52     ` Ingo Molnar
2008-02-19 16:27 99%   ` Ahmed S. Darwish
2008-02-20 10:41         ` Ingo Molnar
2008-02-20 13:37 99%       ` Ahmed S. Darwish
2008-02-20 14:20             ` Dmitry Adamushko
2008-02-20 19:39 99%           ` Ahmed S. Darwish
2007-02-05 16:51 99% [PATCH 00] A series of patches to use ARRAY_SIZE under video subtree Ahmed S. Darwish
     [not found]     <0-v3-7358966cab09+14e9-gup_fork_jgg@nvidia.com>
2020-11-06 18:52 99% ` [PATCH v3 0/2] Add a seqcount between gup_fast and copy_page_range() Ahmed S. Darwish
2007-02-05 16:54 99% [PATCH 00] A series of patches to use ARRAY_SIZE in `net' drivers Ahmed S. Darwish
2007-02-05 16:59 99% ` [PATCH 2.6.20] ibm_emac: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
2007-02-05 20:22       ` Alexey Dobriyan
2007-02-06  9:12 99%     ` Ahmed S. Darwish
2007-02-05 17:00 99% ` [PATCH 2.6.20] wavelan: " Ahmed S. Darwish
2007-02-05 16:59 99% ` [PATCH 2.6.20] ixgb: " Ahmed S. Darwish
2007-02-05 20:18       ` Alexey Dobriyan
2007-02-05 20:31         ` Auke Kok
2007-02-06 10:00 99%       ` Ahmed S. Darwish
2007-02-05 16:58 99% ` [PATCH 2.6.20] hostap: " Ahmed S. Darwish
2007-02-05 16:55 99% ` [PATCH 2.6.20] e1000: " Ahmed S. Darwish
2007-09-24 22:08 99% i386: Fix null interrupt handler (ignore_int) message ? Ahmed S. Darwish
2007-03-18 22:58 99% i386: Why putting __USER_DS in kernel threads stack initialization? Ahmed S. Darwish
2007-03-18 23:15 99% ` Ahmed S. Darwish
2007-03-19 11:23     ` linux-os (Dick Johnson)
2007-03-21 19:25 99%   ` Ahmed S. Darwish
2007-02-23 18:07 99% Video GL rendering worked only between 2.6.20 and 2.6.21-rc1 Ahmed S. Darwish
2011-02-06 17:45 99% [PATCH -next] Documentation: Explain the [KMG] parameters suffix Ahmed S. Darwish
2011-02-07  4:40     ` [PATCH] Documentation: log_buf_len accepts [KMG] Randy Dunlap
2011-02-07 11:40 99%   ` Ahmed S. Darwish
2007-03-17  6:21 99% [PATCH 2.6.21-rc4] kernel/exit: Fix a comment and code contradiction Ahmed S. Darwish
2007-03-17  9:45     ` Johannes Weiner
2007-03-17 15:00 99%   ` Ahmed S. Darwish
2018-09-11 16:26     [PATCH v2 00/10] LSM: Module stacking in support of S.A.R.A and Landlock Casey Schaufler
2018-09-11 16:41     ` [PATCH 01/10] procfs: add smack subdir to attrs Casey Schaufler
2018-09-11 23:45 99%   ` Ahmed S. Darwish
2020-05-19 21:45     [PATCH v1 00/25] seqlock: Extend seqcount API with associated locks Ahmed S. Darwish
2020-05-19 21:45     ` [PATCH v1 07/25] lockdep: Add preemption disabled assertion API Ahmed S. Darwish
2020-05-22 17:55       ` Peter Zijlstra
2020-05-23 14:59         ` Sebastian A. Siewior
2020-05-23 22:41           ` Peter Zijlstra
2020-05-25 10:22             ` Peter Zijlstra
2020-05-26  0:52 99%           ` Ahmed S. Darwish
2020-05-26  8:13                 ` Peter Zijlstra
2020-05-26  9:45 99%               ` Ahmed S. Darwish
2020-07-20 15:55     ` [PATCH v4 00/24] seqlock: Extend seqcount API with associated locks Ahmed S. Darwish
2020-07-20 15:55       ` [PATCH v4 08/24] seqlock: lockdep assert non-preemptibility on seqcount_t write Ahmed S. Darwish
2020-08-08 23:21         ` Guenter Roeck
2020-08-09 18:42 99%       ` Ahmed S. Darwish
2020-07-20 15:55       ` [PATCH v4 01/24] Documentation: locking: Describe seqlock design and usage Ahmed S. Darwish
2020-07-21  1:35         ` Steven Rostedt
2020-07-21  5:34 99%       ` Ahmed S. Darwish
2020-07-20 16:49       ` [PATCH v4 00/24] seqlock: Extend seqcount API with associated locks Eric Biggers
2020-07-20 17:33 99%     ` Ahmed S. Darwish
2020-05-19 21:45     ` [PATCH v1 09/25] Documentation: locking: Describe seqlock design and usage Ahmed S. Darwish
2020-05-22 18:01       ` Peter Zijlstra
2020-05-22 22:24         ` Steven Rostedt
2020-05-25 10:50           ` Ahmed S. Darwish
2020-05-25 11:02 99%         ` Ahmed S. Darwish
2020-08-28  1:07     ` [PATCH v1 0/5] seqlock: Introduce PREEMPT_RT support Ahmed S. Darwish
2020-09-04  6:52       ` peterz
2020-09-04  7:30 99%     ` Ahmed S. Darwish
2020-08-28  1:07       ` [PATCH v1 3/5] seqlock: seqcount_t: Implement all read APIs as statement expressions Ahmed S. Darwish
2020-08-28  8:30         ` peterz
2020-08-28  8:37 99%       ` Ahmed S. Darwish
2020-08-28  1:07       ` [PATCH v1 4/5] seqlock: seqcount_LOCKTYPE_t: Introduce PREEMPT_RT support Ahmed S. Darwish
2020-08-28  8:59         ` peterz
2020-08-28  9:31           ` Ahmed S. Darwish
2020-08-28 14:36 99%         ` Ahmed S. Darwish
2020-08-28  1:07       ` [PATCH v1 2/5] seqlock: Use unique prefix for seqcount_t property accessors Ahmed S. Darwish
2020-08-28  8:27         ` peterz
2020-08-28  8:59 99%       ` Ahmed S. Darwish
2020-08-28  1:07       ` [PATCH v1 1/5] seqlock: seqcount_LOCKTYPE_t: Standardize naming convention Ahmed S. Darwish
2020-08-28  8:18         ` peterz
2020-08-28  8:24 99%       ` Ahmed S. Darwish
2020-08-27 11:40     ` [PATCH v1 0/8] seqlock: Introduce seqcount_latch_t Ahmed S. Darwish
2020-08-27 11:40 99%   ` [PATCH v1 7/8] rbtree_latch: Use seqcount_latch_t Ahmed S. Darwish
2020-08-27 11:40 99%   ` [PATCH v1 4/8] time/sched_clock: " Ahmed S. Darwish
2020-08-27 11:40       ` [PATCH v1 6/8] x86/tsc: " Ahmed S. Darwish
2020-09-04  7:41         ` peterz
2020-09-04  8:03           ` peterz
2020-09-07 16:29             ` Ahmed S. Darwish
2020-09-07 17:30               ` peterz
2020-09-08  6:23 99%             ` Ahmed S. Darwish
2020-05-19 21:45     ` [PATCH v1 01/25] net: core: device_rename: Use rwsem instead of a seqcount Ahmed S. Darwish
2020-05-20 14:37       ` Dan Carpenter
2020-05-25 16:22 99%     ` Ahmed S. Darwish
2020-05-20  2:01       ` Eric Dumazet
2020-05-20  6:42 99%     ` Ahmed S. Darwish
2020-05-20 12:51           ` Eric Dumazet
2020-06-03 14:33 99%         ` Ahmed S. Darwish
2020-05-19 21:45     ` [PATCH v1 04/25] block: nr_sects_write(): Disable preemption on seqcount write Ahmed S. Darwish
     [not found]       ` <20200522001237.A00E8206BE@mail.kernel.org>
2020-05-25 10:12 99%     ` Ahmed S. Darwish
2020-05-22 16:39       ` Peter Zijlstra
2020-05-25  9:56 99%     ` Ahmed S. Darwish
2007-03-09  7:14     [PATCH] drivers/media/video/videocodec.c: check kmalloc() return value Amit Choudhary
2007-03-12 10:45 99% ` Ahmed S. Darwish
2008-02-24 15:55     [BUG + PATCH/Bugfix] x86/lguest: fix pgdir pmd index calculation Ahmed S. Darwish
2008-03-04 12:55     ` Rusty Russell
2008-03-04 15:11 99%   ` Ahmed S. Darwish
2008-02-24 16:18     ` Ingo Molnar
2008-02-24 16:26 99%   ` Ahmed S. Darwish
2007-10-12  7:38     [PATCH try #2] Input/Joystick Driver: add support AD7142 joystick driver Bryan Wu
2007-10-12 16:41 99% ` Ahmed S. Darwish
2007-10-12 17:29       ` Dmitry Torokhov
2007-10-12 19:21 99%     ` Ahmed S. Darwish
2007-02-14 10:02     [patch 0/2] natsemi: Support Aculab E1/T1 cPCI carrier cards Mark Brown
2007-02-14 10:02     ` [patch 1/2] natsemi: Add support for using MII port with no PHY Mark Brown
2007-02-14 13:28 99%   ` Ahmed S. Darwish
2007-05-17 14:45     Fork Bombing Attack Anand Jahagirdar
2007-05-17 15:01     ` Valdis.Kletnieks
2007-05-18 11:13       ` Anand Jahagirdar
2007-05-18 13:19 99%     ` Ahmed S. Darwish
2020-12-22  9:03     [RFC PATCH 0/1] net: arcnet: Fix RESET sequence Ahmed S. Darwish
2021-01-11 13:54 99% ` Ahmed S. Darwish
2021-01-18 10:45 99%   ` Ahmed S. Darwish
2007-10-09 10:43     [PATCH -mm] fix wrong /proc/cpuinfo output Akinobu Mita
2007-10-09 13:32 99% ` Ahmed S. Darwish
2020-07-29 13:52     [PATCH 0/5] seqlock: Cleanups Peter Zijlstra
2020-07-29 13:52     ` [PATCH 5/5] seqcount: More consistent seqprop names Peter Zijlstra
2020-07-29 14:39 99%   ` Ahmed S. Darwish
2020-07-29 13:52     ` [PATCH 1/5] seqlock: s/__SEQ_LOCKDEP/__SEQ_LOCK/g Peter Zijlstra
2020-07-29 14:29 99%   ` Ahmed S. Darwish
2020-07-29 13:52     ` [PATCH 2/5] seqlock: Fold seqcount_LOCKNAME_t definition Peter Zijlstra
2020-07-29 14:38 99%   ` Ahmed S. Darwish
2021-02-23 10:49     [RT v5.11-rt7] WARNING at include/linux/seqlock.h:271 nft_counter_eval Juri Lelli
2021-02-23 11:00     ` Sebastian Andrzej Siewior
2021-02-23 13:53       ` Juri Lelli
2021-02-23 14:20 99%     ` Ahmed S. Darwish
2007-10-09  6:25     [PATCH] Stop docproc segfaulting when SRCTREE isn't set Rob Landley
2007-10-09 13:03 99% ` Ahmed S. Darwish
2007-10-09 15:55       ` Randy Dunlap
2007-10-09 17:19 99%     ` Ahmed S. Darwish
2007-10-09 17:24           ` Randy Dunlap
2007-10-09 17:51 99%         ` Ahmed S. Darwish
2019-03-10  1:31     DRM-based Oops viewer Ahmed S. Darwish
2019-03-11  9:04     ` Jani Nikula
2019-03-11 13:49       ` Daniel Vetter
2019-03-11 23:39 99%     ` Ahmed S. Darwish
2020-09-23 13:56     [RFC 0/2] printk: Add more metadata for each record Petr Mladek
2020-09-23 13:56     ` [RFC 2/2] printk: Add more information about the printk caller Petr Mladek
2020-09-24  4:24 99%   ` Ahmed S. Darwish
2007-10-06 20:14     [Oops] on 2.6.23-rc9 sysRq Show Tasks (t) Ahmed S. Darwish
2007-10-06 20:52 99% ` Ahmed S. Darwish
2007-10-06 21:12     ` Alexey Dobriyan
2007-10-07 19:39 99%   ` Ahmed S. Darwish
2010-12-25  9:57     [PATCH, Bugfix] RAMOOPS: Don't overflow over non-allocated regions Ahmed S. Darwish
2010-12-25 11:19     ` Marco Stornelli
2010-12-27 21:33 99%   ` Ahmed S. Darwish
2007-10-17  4:17     [PATCH] Version 8 (2.6.23) Smack: Simplified Mandatory Access Control Kernel Casey Schaufler
2007-10-18  4:57     ` Al Viro
2007-10-18  5:10       ` Al Viro
2007-10-19 12:39 99%     ` Ahmed S. Darwish
2019-09-08 20:59     Linux 5.3-rc8 Linus Torvalds
2019-09-10  4:21     ` Ahmed S. Darwish
2019-09-10 11:33       ` Linus Torvalds
2019-09-10 17:33         ` Ahmed S. Darwish
2019-09-10 18:21           ` Linus Torvalds
2019-09-11 16:07             ` Theodore Y. Ts'o
2019-09-11 16:45               ` Linus Torvalds
2019-09-11 21:41 99%             ` Ahmed S. Darwish
2019-09-11 22:37 99%               ` Ahmed S. Darwish
2019-09-11 17:00                 ` Linus Torvalds
2019-09-11 17:36                   ` Theodore Y. Ts'o
2019-09-12  3:44                     ` Ahmed S. Darwish
2019-09-12  8:25                       ` Theodore Y. Ts'o
2019-09-12 11:34                         ` Linus Torvalds
2019-09-14 12:25                           ` [PATCH RFC] random: getrandom(2): don't block on non-initialized entropy pool Ahmed S. Darwish
2019-09-14 14:08                             ` Alexander E. Patrakov
2019-09-15  5:22                               ` [PATCH RFC v2] random: optionally block in getrandom(2) when the CRNG is uninitialized Theodore Y. Ts'o
2019-09-15 17:32                                 ` Linus Torvalds
2019-09-18 21:15                                   ` [PATCH RFC v4 0/1] random: WARN on large getrandom() waits and introduce getrandom2() Ahmed S. Darwish
2019-09-18 21:17                                     ` [PATCH RFC v4 1/1] " Ahmed S. Darwish
2019-09-18 23:57                                       ` Linus Torvalds
2019-09-20 13:46                                         ` Ahmed S. Darwish
2019-09-20 14:33                                           ` Andy Lutomirski
2019-09-20 16:29                                             ` Linus Torvalds
2019-09-20 17:52                                               ` Andy Lutomirski
2019-09-20 18:09                                                 ` Linus Torvalds
2019-09-21  6:07                                                   ` Florian Weimer
2019-09-23 18:33                                                     ` Andy Lutomirski
2019-09-26 21:11 99%                                                   ` Ahmed S. Darwish
2019-09-20 17:26                                           ` Willy Tarreau
2019-09-20 17:56 99%                                         ` Ahmed S. Darwish
2019-09-14 15:02                           ` Linux 5.3-rc8 Ahmed S. Darwish
2019-09-14 16:30                             ` Linus Torvalds
2019-09-15  6:51                               ` Lennart Poettering
2019-09-15  7:27 99%                             ` Ahmed S. Darwish
2019-09-15 16:29                                 ` Linus Torvalds
2019-09-16  1:40                                   ` Ahmed S. Darwish
2019-09-16  1:48                                     ` Vito Caputo
2019-09-16  2:49                                       ` Theodore Y. Ts'o
2019-09-16  4:29                                         ` Willy Tarreau
2019-09-16  5:02                                           ` Linus Torvalds
2019-09-16  6:12                                             ` Willy Tarreau
2019-09-16 16:17                                               ` Linus Torvalds
2019-09-16 17:21                                                 ` Theodore Y. Ts'o
2019-09-16 19:53 99%                                               ` Ahmed S. Darwish
2007-10-25  3:46     [PATCH 2/2] Version 9 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel Casey Schaufler
2007-10-27  9:01     ` Ahmed S. Darwish
2007-10-27 23:47       ` Al Viro
2007-10-28 12:46 99%     ` Ahmed S. Darwish
2008-02-06 23:21     [Lguest/x86]: Clash with ioremap_nocache() + _PAGE_PWT Ahmed S. Darwish
2008-02-06 23:59     ` Ingo Molnar
2008-02-07  0:51 99%   ` [PATCH] lguest: Accept guest _PAGE_PWT page table entries Ahmed S. Darwish
2007-03-29 10:04     Student Project Ideas Russ Meyerriecks
2007-03-29 20:44 99% ` Ahmed S. Darwish
2008-02-26 23:22     [PATCH -mm 0/4] LSM interfaced Audit (SELinux audit separation) Ahmed S. Darwish
2008-02-26 23:24     ` [PATCH -mm 1/4] LSM: Introduce inode_getsecid and ipc_getsecid hooks Ahmed S. Darwish
2008-02-27 16:04       ` Paul Moore
2008-02-27 16:45 99%     ` Ahmed S. Darwish
2020-09-04 15:32     [PATCH v2 0/5] seqlock: Introduce PREEMPT_RT support Ahmed S. Darwish
2020-09-04 15:32     ` [PATCH v2 4/5] seqlock: seqcount_LOCKNAME_t: " Ahmed S. Darwish
2020-09-08 11:45       ` peterz
2020-09-08 12:48 99%     ` Ahmed S. Darwish
2018-08-27 23:14     [PATCH 01/13] seq_file: rewrite seq_puts() in terms of seq_write() Alexey Dobriyan
2018-08-27 23:15     ` [PATCH 11/13] proc: readdir /proc/*/task Alexey Dobriyan
2018-08-28 12:36 99%   ` Ahmed S. Darwish
2007-11-01 15:54     [PATCH] Smackv9: Use a stateful parser for parsing Smack rules Ahmed S. Darwish
2007-11-01 17:29     ` Jan Engelhardt
2007-11-02 18:50 99%   ` Ahmed S. Darwish
2020-06-23  8:36     [PATCH v4 0/8] lockdep: Change IRQ state tracking to use per-cpu variables Peter Zijlstra
2020-06-23  8:36     ` [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to " Peter Zijlstra
2020-06-23 15:00 99%   ` Ahmed S. Darwish
2020-06-23 15:24         ` Peter Zijlstra
2020-06-23 16:13 99%       ` Ahmed S. Darwish
2020-06-30  5:59 99%   ` Ahmed S. Darwish
2007-07-01 20:38     [i386] Questions regarding provisional page tables initialization Ahmed S. Darwish
2007-07-01 22:19     ` Jeremy Fitzhardinge
2007-07-02  1:13 99%   ` Ahmed S. Darwish
2007-07-02  9:18         ` Andreas Schwab
2007-07-02 10:23           ` Ahmed S. Darwish
2007-07-02 11:34             ` Brian Gerst
2007-07-02 15:43 99%           ` Ahmed S. Darwish
2021-01-12 11:11     [PATCH] MAINTAINERS: Remove intel-linux-scu@intel.com for INTEL C600 SAS DRIVER John Garry
2021-01-12 11:37 99% ` Ahmed S. Darwish
2008-03-04 17:45     [PATCH BUGFIX -rc3] Smack: Don't register smackfs if we're not loaded Casey Schaufler
2008-03-05 12:44 99% ` Ahmed S. Darwish
2008-03-05 12:51 99%   ` Ahmed S. Darwish
2008-02-25  1:41     2.6.25-rc3: Reported regressions from 2.6.24 Rafael J. Wysocki
2008-02-25 18:24 99% ` Ahmed S. Darwish
2021-01-12 11:06     [PATCH v2 00/19] scsi: libsas: Remove in_interrupt() check Ahmed S. Darwish
2021-01-12 11:53     ` John Garry
2021-01-12 13:19 99%   ` Ahmed S. Darwish
2021-01-12 16:00         ` John Garry
2021-01-12 17:33           ` Ahmed S. Darwish
2021-01-14  9:51             ` John Garry
2021-01-15 16:27 99%           ` Ahmed S. Darwish
2021-01-15 16:29                 ` John Garry
2021-01-15 16:41 99%               ` Ahmed S. Darwish
2021-01-12 11:06     ` [PATCH v2 04/19] scsi: mvsas: Pass gfp_t flags to libsas event notifiers Ahmed S. Darwish
2021-01-12 15:46       ` Christoph Hellwig
2021-01-12 17:03 99%     ` Ahmed S. Darwish
2021-01-12 11:06     ` [PATCH v2 02/19] scsi: libsas and users: Remove notifier indirection Ahmed S. Darwish
2021-01-12 11:36       ` John Garry
2021-01-12 12:09 99%     ` Ahmed S. Darwish
2010-12-21 23:30     Linux 2.6.37-rc7 Jochen Voss
2010-12-22 18:18 99% ` Ahmed S. Darwish
2007-10-13  7:15     2.6.23-git2 buid failure Kamalesh Babulal
2007-10-14 11:18 99% ` Ahmed S. Darwish
2008-03-17 23:14     [PATCH] de-semaphorize smackfs Jonathan Corbet
2008-03-18  7:35     ` Christoph Hellwig
2008-03-18 12:01 99%   ` Ahmed S. Darwish
2008-05-30 23:36     [PATCH BUGFIX -rc4] Smack: Respect 'unlabeled' netlabel mode Ahmed S. Darwish
2008-05-30 23:57     ` [PATCH BUGFIX -v2 " Ahmed S. Darwish
2008-05-30 23:25       ` Andrew Morton
2008-05-31  1:12 99%     ` Ahmed S. Darwish
2008-03-01 21:11     [RFC PATCH -mm] LSM: Add lsm= boot parameter Adrian Bunk
2008-03-01 21:29     ` Casey Schaufler
2008-03-01 23:27       ` [PATCH -v2 -mm] LSM: Add security= " Ahmed S. Darwish
2008-03-02  7:49 99%     ` Ahmed S. Darwish
2008-03-02 10:59           ` [PATCH -v3 " Ahmed S. Darwish
2008-03-03  8:29             ` James Morris
2008-03-03 15:35               ` Ahmed S. Darwish
2008-03-03 15:54                 ` Stephen Smalley
2008-03-03 21:24                   ` [PATCH -v4 " Ahmed S. Darwish
2008-03-03 22:16                     ` James Morris
2008-03-04  3:04                       ` [PATCH -v5 " Ahmed S. Darwish
2008-03-05 22:29                         ` Andrew Morton
2008-03-05 22:56                           ` Ahmed S. Darwish
2008-03-05 23:06 99%                         ` Ahmed S. Darwish
2008-03-02  3:41         ` [PATCH -v2 " Casey Schaufler
2008-03-02  7:55 99%       ` Ahmed S. Darwish
2007-02-06 16:02     [PATCH 00] A series of patches to use ARRAY_SIZE macro Ahmed S. Darwish
2007-02-06 16:08 99% ` [PATCH 2.6.20] reiserfs: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
2007-02-06 16:09 99% ` [PATCH 2.6.20] w1: " Ahmed S. Darwish
2007-02-06 16:08 99% ` [PATCH 2.6.20] rcutorture: " Ahmed S. Darwish
2007-02-06 16:07 99% ` [PATCH 2.6.20] infinband: " Ahmed S. Darwish
2007-02-06 16:04 99% ` [PATCH 2.6.20] isdn-capi: " Ahmed S. Darwish
2007-02-06 17:52       ` Joe Perches
2007-02-06 20:41         ` Ahmed S. Darwish
2007-02-06 21:18           ` Philippe De Muyter
2007-02-07 19:41 99%         ` Ahmed S. Darwish
2007-02-06 16:08 99% ` [PATCH 2.6.20] intel-agp: " Ahmed S. Darwish
2007-02-06 16:07 99% ` [PATCH 2.6.20] s390-drivers: " Ahmed S. Darwish
2007-02-06 16:09 99% ` [PATCH 2.6.20] toshiba-acpi: " Ahmed S. Darwish
2007-02-06 16:06 99% ` [PATCH 2.6.20] drivers/md.c: " Ahmed S. Darwish
2007-02-06 16:10 99% ` [PATCH 2.6.20] drm: " Ahmed S. Darwish
2014-12-23 15:46     [PATCH] can: kvaser_usb: Don't free packets when tight on URBs Ahmed S. Darwish
2015-01-11 20:05 99% ` [PATCH v4 00/04] can: Introduce support for Kvaser USBCAN-II devices Ahmed S. Darwish
2015-01-11 20:11       ` [PATCH v4 01/04] can: kvaser_usb: Don't dereference skb after a netif_rx() devices Ahmed S. Darwish
2015-01-11 20:15 99%     ` [PATCH v4 2/4] can: kvaser_usb: Update error counters before exiting on OOM Ahmed S. Darwish
2015-01-11 20:36           ` [PATCH v4 3/4] can: kvaser_usb: Add support for the Usbcan-II family Ahmed S. Darwish
2015-01-12 11:20 99%         ` Ahmed S. Darwish
2015-01-11 20:45             ` [PATCH v4 4/4] can: kvaser_usb: Retry first bulk transfer on -ETIMEDOUT Ahmed S. Darwish
2015-01-11 20:51               ` Marc Kleine-Budde
2015-01-12 10:14 99%             ` Ahmed S. Darwish
2015-01-12 13:33                   ` Olivier Sobrie
2015-01-12 13:50 99%                 ` Ahmed S. Darwish
2015-01-12 11:43             ` [PATCH v4 3/4] can: kvaser_usb: Add support for the Usbcan-II family Marc Kleine-Budde
2015-01-12 12:07 99%           ` Ahmed S. Darwish
2015-01-12 12:36 99%             ` Ahmed S. Darwish
2015-01-26  5:17     ` [PATCH v6 0/7] can: kvaser_usb: Leaf bugfixes and USBCan-II support Ahmed S. Darwish
2015-01-26  5:20       ` [PATCH v6 1/7] can: kvaser_usb: Do not sleep in atomic context Ahmed S. Darwish
2015-01-26  5:22 99%     ` [PATCH v6 2/7] can: kvaser_usb: Send correct context to URB completion Ahmed S. Darwish
2015-01-05 17:49     ` [PATCH v3 1/4] can: kvaser_usb: Don't free packets when tight on URBs Ahmed S. Darwish
2015-01-05 17:52       ` [PATCH v3 2/4] can: kvaser_usb: Reset all URB tx contexts upon channel close Ahmed S. Darwish
2015-01-05 17:57         ` [PATCH v3 3/4] can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels Ahmed S. Darwish
2015-01-05 18:31           ` [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family Ahmed S. Darwish
2015-01-08 11:53             ` Marc Kleine-Budde
2015-01-09  3:06 99%           ` Ahmed S. Darwish
2015-01-08 15:19               ` Ahmed S. Darwish
2015-01-12 11:51                 ` Marc Kleine-Budde
2015-01-12 12:26 99%               ` Ahmed S. Darwish
2015-01-20 21:44     ` [PATCH v5 1/5] can: kvaser_usb: Update net interface state before exiting on OOM Ahmed S. Darwish
2015-01-20 21:45       ` [PATCH v5 2/5] can: kvaser_usb: Consolidate and unify state change handling Ahmed S. Darwish
2015-01-21 16:20         ` Andri Yngvason
2015-01-25  3:21 99%       ` Ahmed S. Darwish
2015-01-21 22:59           ` Marc Kleine-Budde
2015-01-22 10:14             ` Andri Yngvason
2015-01-25  2:49 99%           ` Ahmed S. Darwish
2015-01-20 21:47         ` [PATCH v5 3/5] can: kvaser_usb: Fix state handling upon BUS_ERROR events Ahmed S. Darwish
2015-01-20 21:48           ` [PATCH v5 4/5] can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT Ahmed S. Darwish
2015-01-21 12:24             ` Sergei Shtylyov
2015-01-25 11:59 99%           ` Ahmed S. Darwish
2015-01-01 21:59     ` [PATCH] can: kvaser_usb: Don't free packets when tight on URBs Stephen Hemminger
2015-01-03 14:34 99%   ` Ahmed S. Darwish
2014-12-24 23:56     ` [PATCH v2 1/4] " Ahmed S. Darwish
2014-12-25  2:50       ` Greg KH
2014-12-25  9:38 99%     ` Ahmed S. Darwish
2014-12-24 12:31     ` [PATCH] " Olivier Sobrie
2014-12-24 15:52 99%   ` Ahmed S. Darwish
2014-12-23 15:53     ` [PATCH] can: kvaser_usb: Add support for the Usbcan-II family Ahmed S. Darwish
2014-12-24 12:36       ` Olivier Sobrie
2014-12-24 15:04         ` Ahmed S. Darwish
2014-12-28 21:51           ` Olivier Sobrie
2014-12-30 15:33 99%         ` Ahmed S. Darwish
2020-08-17 13:50     v5.9-rc1 commit reliably breaks pci nvme detection Ahmed S. Darwish
2020-08-17 15:56     ` Keith Busch
2020-08-17 15:58       ` Jens Axboe
2020-08-20 15:35         ` Jens Axboe
2020-08-20 17:07 99%       ` Ahmed S. Darwish
2007-10-15 14:47     [PATCH try #3] Input/Joystick Driver: add support AD7142 joystick driver Bryan Wu
2007-10-15 15:48     ` Dmitry Torokhov
2007-10-15 18:27 99%   ` Ahmed S. Darwish
2007-10-16  6:08         ` Bryan Wu
2007-10-16 16:40 99%       ` Ahmed S. Darwish
2007-09-19  8:45     PROBLEM: System Freeze on Particular workload with kernel 2.6.22.6 Low Yucheng
2007-09-19 15:47     ` Oleg Verych
2007-09-19 16:16       ` Low Yucheng
2007-09-19 19:25 99%     ` Ahmed S. Darwish
2007-09-20 10:00           ` Jarek Poplawski
2007-09-20 15:24 99%         ` Ahmed S. Darwish
2020-07-15  2:05     [PATCH v2 0/6] arm64: perf: Proper cap_user_time* support Leo Yan
2020-07-15  2:05     ` [PATCH v2 1/6] sched_clock: Expose struct clock_read_data Leo Yan
2020-07-15  5:56       ` Ahmed S. Darwish
2020-07-15  6:54         ` Leo Yan
2020-07-15  7:21 99%       ` Ahmed S. Darwish
2007-11-02 20:50     [PATCH] Version 10 (2.6.24-rc1) Smack: Simplified Mandatory Access Control Kernel Casey Schaufler
2007-11-03 16:43     ` [PATCH] Smackv10: Smack rules grammar + their stateful parser Ahmed S. Darwish
2007-11-04 20:06 99%   ` Ahmed S. Darwish
2007-11-05  0:56       ` [PATCH] Smackv10: Smack rules grammar + their stateful parser(2) Ahmed S. Darwish
2007-11-10 17:05         ` Jakob Oestergaard
2007-11-10 19:45 99%       ` Ahmed S. Darwish
2007-11-11 12:44         ` Pavel Machek
2007-11-11 18:37 99%       ` Ahmed S. Darwish
2007-11-04 12:28       ` [PATCH] Smackv10: Smack rules grammar + their stateful parser Pavel Machek
2007-11-05  9:41 99%     ` Ahmed S. Darwish
2007-11-05 16:21           ` Linus Torvalds
2007-11-05 23:38 99%         ` Ahmed S. Darwish
2007-11-04 13:23 99%     ` Ahmed S. Darwish
2007-11-03 18:30       ` Kyle Moffett
2007-11-03 22:12 99%     ` Ahmed S. Darwish
2007-11-06  6:33       ` Adrian Bunk
2007-11-06  8:26         ` Kyle Moffett
2007-11-06  8:56           ` Adrian Bunk
2007-11-06 11:34 99%         ` Ahmed S. Darwish
2007-11-06 11:47               ` Adrian Bunk
2007-11-06 12:23 99%             ` Ahmed S. Darwish
2007-11-06 12:49                   ` Kyle Moffett
2007-11-06 13:34                     ` Adrian Bunk
2007-11-06 14:05 99%                   ` Ahmed S. Darwish
2007-11-06 14:10                         ` Adrian Bunk
2007-11-06 14:30 99%                       ` Ahmed S. Darwish
2007-02-05  2:39     [PATCH 00] A series of patches to use ARRAY_SIZE macro under arch/ Ahmed S. Darwish
2007-02-05  2:41 99% ` [PATCH 2.6.20] arch AVR32: Use ARRAY_SIZE macro when appropriate Ahmed S. Darwish
2007-02-05  2:40 99% ` [PATCH 2.6.20] arch CRIS: user " Ahmed S. Darwish
2007-02-05  2:43 99% ` [PATCH 2.6.20] arch ARM: Use " Ahmed S. Darwish
2020-12-01  6:46     [PATCH] scsi/NCR5380: Remove in_interrupt() test Finn Thain
2020-12-01 17:05     ` Sebastian Andrzej Siewior
2020-12-03 23:08       ` Finn Thain
2020-12-04 16:08 99%     ` Ahmed S. Darwish
2021-01-21 13:45     [ANNOUNCE] v5.11-rc4-rt1 Sebastian Andrzej Siewior
2021-01-21 20:50     ` Pavel Machek
2021-01-22  5:32 99%   ` Ahmed S. Darwish
2015-02-26 15:20     [PATCH 1/5] can: kvaser_usb: Avoid double free on URB submission failures Ahmed S. Darwish
2015-03-15 15:03     ` [PATCH v5 1/2] can: kvaser_usb: Comply with firmware max tx URBs value Ahmed S. Darwish
2015-03-15 18:08       ` Marc Kleine-Budde
2015-03-16 12:16 99%     ` Ahmed S. Darwish
2015-02-26 15:22     ` [PATCH 2/5] can: kvaser_usb: Read all messages in a bulk-in URB buffer Ahmed S. Darwish
2015-02-26 15:24       ` [PATCH 3/5] can: kvaser_usb: Utilize all possible tx URBs Ahmed S. Darwish
2015-02-26 15:25 99%     ` [PATCH 4/5] can: kvaser_usb: Use can-dev unregistration mechanism Ahmed S. Darwish
2015-03-11 17:37     ` [PATCH v3 1/3] can: kvaser_usb: Fix tx queue start/stop race conditions Ahmed S. Darwish
2015-03-11 17:39       ` [PATCH v3 2/3] can: kvaser_usb: Utilize all possible tx URBs Ahmed S. Darwish
2015-03-11 17:39 99%     ` [PATCH v3 3/3] can: kvaser_usb: Use can-dev unregistration mechanism Ahmed S. Darwish
2015-03-11 21:53         ` [PATCH v3 2/3] can: kvaser_usb: Utilize all possible tx URBs Marc Kleine-Budde
2015-03-12 10:52 99%       ` Ahmed S. Darwish
2015-03-14 13:02     ` [PATCH v4 1/3] can: kvaser_usb: Fix tx queue start/stop race conditions Ahmed S. Darwish
2015-03-14 13:09       ` [PATCH v4 2/3] can: kvaser_usb: Utilize all possible tx URBs Ahmed S. Darwish
2015-03-14 13:11 99%     ` [PATCH v4 3/3] can: kvaser_usb: Use can-dev unregistration mechanism Ahmed S. Darwish
2015-03-14 15:26           ` Marc Kleine-Budde
2015-03-14 15:41 99%         ` Ahmed S. Darwish
2015-03-14 15:55               ` Marc Kleine-Budde
2015-03-14 16:06 99%             ` Ahmed S. Darwish
2015-03-14 13:41       ` [PATCH v4 1/3] can: kvaser_usb: Fix tx queue start/stop race conditions Marc Kleine-Budde
2015-03-14 14:38         ` Ahmed S. Darwish
2015-03-14 14:58           ` Marc Kleine-Budde
2015-03-14 15:19 99%         ` Ahmed S. Darwish
2015-03-11 15:23     ` [PATCH v2 " Ahmed S. Darwish
2015-03-11 15:36       ` Marc Kleine-Budde
2015-03-11 15:57 99%     ` Ahmed S. Darwish
2015-03-11 15:28       ` [PATCH v2 2/3] can: kvaser_usb: Utilize all possible tx URBs Ahmed S. Darwish
2015-03-11 15:30 99%     ` [PATCH v2 3/3] can: kvaser_usb: Use can-dev unregistration mechanism Ahmed S. Darwish
2015-03-04  9:15     ` [PATCH 1/5] can: kvaser_usb: Avoid double free on URB submission failures Marc Kleine-Budde
2015-03-09 12:32 99%   ` Ahmed S. Darwish
2007-09-26 22:33     [PATCH 1/3] Completely remove deprecated IRQ flags (SA_*) Ahmed S. Darwish
2007-09-26 22:35 99% ` [PATCH 2/3] MIPS: Remove " Ahmed S. Darwish
2008-03-06 12:19     [PATCH -v8 -rc3] Security: Introduce security= boot parameter Ahmed S. Darwish
2008-03-06 13:31     ` James Morris
2008-03-06 14:32 99%   ` Ahmed S. Darwish
2020-12-22 12:54     [PATCH 00/11] scsi: libsas: Remove in_interrupt() check John Garry
2021-01-11 13:43 99% ` Ahmed S. Darwish
2021-01-11 13:59       ` John Garry
2021-01-11 14:28 99%     ` Ahmed S. Darwish
2008-09-25 17:25     SMACK netfilter smacklabel socket match Tilman Baumann
2008-09-26  8:19     ` Tilman Baumann
2008-09-27  5:01       ` Casey Schaufler
2008-09-29 16:21         ` Tilman Baumann
2008-09-30  3:29           ` Casey Schaufler
2008-10-01 11:29             ` Tilman Baumann
2008-10-01 15:21               ` Casey Schaufler
2008-10-01 16:55                 ` Tilman Baumann
2008-10-01 18:22                   ` Casey Schaufler
2008-10-06 12:57                     ` Tilman Baumann
2008-10-06 23:05 99%                   ` Ahmed S. Darwish
2007-03-25  8:29     [PATCH] net: tun/tap: fixed hw address handling Brian Braunstein
2007-03-26 20:55 99% ` Ahmed S. Darwish
2007-03-26 21:05 99%   ` Ahmed S. Darwish
2020-11-03  0:17     [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during fork Ahmed S. Darwish
     [not found]     ` <20201103002532.GL2620339@nvidia.com>
2020-11-03  0:41       ` Ahmed S. Darwish
2020-11-03  2:20         ` John Hubbard
2020-11-03  6:52           ` Ahmed S. Darwish
2020-11-03 17:40             ` Linus Torvalds
2020-11-04  1:32               ` Ahmed S. Darwish
2020-11-04  2:01                 ` John Hubbard
2020-11-04  3:17                   ` Ahmed S. Darwish
2020-11-04 18:38                     ` Linus Torvalds
2020-11-04 19:54 99%                   ` Ahmed S. Darwish
2007-01-18  4:15     after effects of a kernel API change Daniel Rodrick
2007-01-18  5:10 99% ` Ahmed S. Darwish
2007-01-18  5:35       ` Rajat Jain
2007-01-18  9:44 99%     ` Ahmed S. Darwish
2020-06-30  5:44     [PATCH v3 00/20] seqlock: Extend seqcount API with associated locks Ahmed S. Darwish
2020-06-30  5:44     ` [PATCH v3 06/20] " Ahmed S. Darwish
2020-07-06 21:21       ` Peter Zijlstra
2020-07-07  8:40         ` Ahmed S. Darwish
2020-07-07 13:04           ` Peter Zijlstra
2020-07-07 14:37             ` Peter Zijlstra
2020-07-08  9:12               ` Peter Zijlstra
2020-07-08 10:43 99%             ` Ahmed S. Darwish
2020-07-08 10:33               ` Ahmed S. Darwish
2020-07-08 12:29                 ` Peter Zijlstra
2020-07-08 15:09 99%               ` Ahmed S. Darwish
2020-07-08 15:35                     ` Peter Zijlstra
2020-07-08 15:58 99%                   ` Ahmed S. Darwish
2020-06-30  5:44     ` [PATCH v3 01/20] Documentation: locking: Describe seqlock design and usage Ahmed S. Darwish
2020-07-06 21:04       ` Peter Zijlstra
2020-07-07 10:12 99%     ` Ahmed S. Darwish
2020-12-18 20:43     [PATCH 00/11] scsi: libsas: Remove in_interrupt() check Ahmed S. Darwish
2020-12-18 20:43     ` [PATCH 11/11] scsi: libsas: event notifiers: Remove non _gfp() variants Ahmed S. Darwish
2020-12-21 17:17       ` John Garry
2020-12-21 17:38 99%     ` Ahmed S. Darwish
2007-10-08 12:34     PROBLEM: kernel 2.6.22.9-cfs-v22 compile warnings Konstantin Oshovskij
2007-10-08 18:11 99% ` Ahmed S. Darwish
2008-03-01 19:47     [PATCH-v2 -mm 0/9] LSM-neutral Audit (SELinux audit separation) Ahmed S. Darwish
2008-03-01 20:01     ` [PATCH 7/9] Audit: internally use the new LSM audit hooks Ahmed S. Darwish
2008-03-03 23:51       ` Paul Moore
2008-03-04  3:31 99%     ` Ahmed S. Darwish
2020-12-24 13:11     [RFC PATCH 0/3] chelsio: cxgb: Use threaded irqs Ahmed S. Darwish
2020-12-24 13:11     ` [RFC PATCH 1/3] chelsio: cxgb: Remove ndo_poll_controller() Ahmed S. Darwish
2020-12-24 13:31 99%   ` Ahmed S. Darwish
2020-08-10  8:59     [PATCH v4 08/24] seqlock: lockdep assert non-preemptibility on seqcount_t write Greg KH
2020-08-10  9:54     ` [PATCH] Revert "seqlock: lockdep assert non-preemptibility on seqcount_t write" Ahmed S. Darwish
2020-08-10 10:05       ` Greg KH
2020-08-10 10:35 99%     ` Ahmed S. Darwish
2007-10-08 21:55     [PATCH] NTFS error messages: replace static char pointers by static char arrays Dmitri Vorobiev
2007-10-09 12:40 99% ` Ahmed S. Darwish
2007-10-09 18:33       ` Philipp Matthias Hahn
2007-10-09 22:03 99%     ` Ahmed S. Darwish
2021-01-11 17:28     [PATCH] scsi: libsas and users: Remove notifier indirection John Garry
2021-01-12 11:25 99% ` Ahmed S. Darwish
2021-01-11 17:41 99% ` Ahmed S. Darwish
2021-01-11 17:44       ` John Garry
2021-01-11 17:52 99%     ` Ahmed S. Darwish
2008-03-12 15:40     [RFC][PATCH -v2] Smack: Integrate with Audit Casey Schaufler
2008-03-12 15:48     ` Stephen Smalley
2008-03-12 16:43 99%   ` Ahmed S. Darwish
2015-01-16 19:16     [PATCH v3 00/13] Add kdbus implementation Greg Kroah-Hartman
2015-01-16 19:16     ` [PATCH 01/13] kdbus: add documentation Greg Kroah-Hartman
2015-01-23  6:28 99%   ` Ahmed S. Darwish
2015-01-23 13:19         ` Greg Kroah-Hartman
2015-01-25  3:30 99%       ` Ahmed S. Darwish
2008-02-15 18:42     Linux i386 clone(): %ebx 'frobbing' ? Ahmed S. Darwish
2008-02-15 20:07     ` Andreas Schwab
2008-02-15 23:07 99%   ` Ahmed S. Darwish
2008-02-15 23:28         ` Andreas Schwab
2008-02-15 23:54 99%       ` Ahmed S. Darwish


LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lkml.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lkml.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lkml.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lkml.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lkml.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lkml.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lkml.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lkml.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lkml.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lkml.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lkml.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git