Re: [PATCH] fs: omfs: use kmemdup() rather than kmalloc+memcpy
On Wed, Sep 09, 2020 at 08:04:15PM +0100, Alex Dewar wrote: > On 24/08/2020 22:17, Alex Dewar wrote: > > Issue identified with Coccinelle. > Gentle ping? > > > > Signed-off-by: Alex Dewar Acked-by: Bob Copeland However, I don't have a git tree for OMFS so you'll need to send it through vfs tree or so. -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH] fs: omfs: Use kmemdup rather than duplicating its implementation in omfs_get_imap
On Tue, Sep 03, 2019 at 02:39:44PM +0800, zhong jiang wrote: > kmemdup contains the kmalloc + memcpy. hence it is better to use kmemdup > directly. Just replace it. > > Signed-off-by: zhong jiang This same patch was already sent to me by someone else and I acked it: https://lore.kernel.org/lkml/20190703163158.937-1-huangfq.dax...@gmail.com/ -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH] omfs: Fix a memory leak bug
On Tue, Aug 20, 2019 at 01:22:59AM -0500, Wenwen Wang wrote: > In omfs_get_imap(), 'sbi->s_imap' is allocated through kcalloc(). However, > it is not deallocated in the following execution if 'block' is not less > than 'sbi->s_num_blocks', leading to a memory leak bug. To fix this issue, > go to the 'nomem_free' label to free 'sbi->s_imap'. Nice catch, thanks. Acked-by: Bob Copeland -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH 18/20] fs: omfs: Initialize filesystem timestamp ranges
On Mon, Jul 29, 2019 at 06:49:22PM -0700, Deepa Dinamani wrote: > Fill in the appropriate limits to avoid inconsistencies > in the vfs cached inode times when timestamps are > outside the permitted range. > > Signed-off-by: Deepa Dinamani > Cc: m...@bobcopeland.com > Cc: linux-karma-de...@lists.sourceforge.net > --- > fs/omfs/inode.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c > index 08226a835ec3..b76ec6b88ded 100644 > --- a/fs/omfs/inode.c > +++ b/fs/omfs/inode.c > @@ -478,6 +478,10 @@ static int omfs_fill_super(struct super_block *sb, void > *data, int silent) > > sb->s_maxbytes = 0x; > > + sb->s_time_gran = NSEC_PER_MSEC; > + sb->s_time_min = 0; > + sb->s_time_max = U64_MAX / MSEC_PER_SEC; > + I honestly don't know if it should be s64 rather than u64, but considering that none of the devices with this filesystem ever exposed dates to users in the negative era, it should be fine. Acked-by: Bob Copeland -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH] fs/omfs: make use of kmemdup
On Sun, Jul 21, 2019 at 04:53:27PM +0530, Hariprasad Kelam wrote: > kmalloc + memcpy can be replaced with kmemdup. > > fix below issue reported by coccicheck > ./fs/omfs/inode.c:366:9-16: WARNING opportunity for kmemdup > > Signed-off-by: Hariprasad Kelam Thanks! Acked-by: Bob Copeland -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH v2 32/35] omfs: Use kmemdup rather than duplicating its implementation
On Thu, Jul 04, 2019 at 12:31:58AM +0800, Fuqian Huang wrote: > kmemdup is introduced to duplicate a region of memory in a neat way. > Rather than kmalloc/kzalloc + memcpy, which the programmer needs to > write the size twice (sometimes lead to mistakes), kmemdup improves > readability, leads to smaller code and also reduce the chances of mistakes. > Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy. Acked-by: Bob Copeland -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH] ath10k: transmit queued frames after waking queues
On Fri, May 25, 2018 at 02:36:56PM +0200, Niklas Cassel wrote: > A spin lock does have the advantage of ordering: memory operations issued > before the spin_unlock_bh() will be completed before the spin_unlock_bh() > operation has completed. > > However, ath10k_htt_tx_dec_pending() was called earlier in the same function, > which decreases htt->num_pending_tx, so that write will be completed before > our read. That is the only ordering we care about here (if we should call > ath10k_mac_tx_push_pending() or not). Sure. I also understand that reading inside a lock and operating on the value outside the lock isn't really the definition of synchronization (doesn't really matter in this case though). I was just suggesting that the implicit memory barrier in the spin unlock that we are already paying for would be sufficient here too, and it matches the semantic of "tx fields under tx_lock." On the other hand, maybe it's just me, but I tend to look askance at just-in-case READ_ONCEs sprinkled about. -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH] ath10k: transmit queued frames after waking queues
On Fri, May 25, 2018 at 02:36:56PM +0200, Niklas Cassel wrote: > A spin lock does have the advantage of ordering: memory operations issued > before the spin_unlock_bh() will be completed before the spin_unlock_bh() > operation has completed. > > However, ath10k_htt_tx_dec_pending() was called earlier in the same function, > which decreases htt->num_pending_tx, so that write will be completed before > our read. That is the only ordering we care about here (if we should call > ath10k_mac_tx_push_pending() or not). Sure. I also understand that reading inside a lock and operating on the value outside the lock isn't really the definition of synchronization (doesn't really matter in this case though). I was just suggesting that the implicit memory barrier in the spin unlock that we are already paying for would be sufficient here too, and it matches the semantic of "tx fields under tx_lock." On the other hand, maybe it's just me, but I tend to look askance at just-in-case READ_ONCEs sprinkled about. -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH] ath10k: transmit queued frames after waking queues
On Mon, May 21, 2018 at 10:37:01PM +0200, Niklas Cassel wrote: > On Thu, May 17, 2018 at 03:26:25PM -0700, Adrian Chadd wrote: > > On Thu, 17 May 2018 at 16:16, Niklas Cassel <niklas.cas...@linaro.org> > > wrote: > > > > > diff --git a/drivers/net/wireless/ath/ath10k/txrx.c > > b/drivers/net/wireless/ath/ath10k/txrx.c > > > index cda164f6e9f6..1d3b2d2c3fee 100644 > > > --- a/drivers/net/wireless/ath/ath10k/txrx.c > > > +++ b/drivers/net/wireless/ath/ath10k/txrx.c > > > @@ -95,6 +95,9 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt, > > > wake_up(>empty_tx_wq); > > > spin_unlock_bh(>tx_lock); > > > > > + if (htt->num_pending_tx <= 3 && !list_empty(>txqs)) > > > + ath10k_mac_tx_push_pending(ar); > > > + > > > > Just sanity checking - what's protecting htt->num_pending_tx? or is it > > serialised some other way? [...] > I can't see that any of the examples applies, but let's add READ_ONCE(), > to make sure that the compiler doesn't try to optimize this. Couldn't you just move the num_pending_tx read inside tx_lock which is 2 lines above? I think all the other manipulations are protected by tx_lock. -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH] ath10k: transmit queued frames after waking queues
On Mon, May 21, 2018 at 10:37:01PM +0200, Niklas Cassel wrote: > On Thu, May 17, 2018 at 03:26:25PM -0700, Adrian Chadd wrote: > > On Thu, 17 May 2018 at 16:16, Niklas Cassel > > wrote: > > > > > diff --git a/drivers/net/wireless/ath/ath10k/txrx.c > > b/drivers/net/wireless/ath/ath10k/txrx.c > > > index cda164f6e9f6..1d3b2d2c3fee 100644 > > > --- a/drivers/net/wireless/ath/ath10k/txrx.c > > > +++ b/drivers/net/wireless/ath/ath10k/txrx.c > > > @@ -95,6 +95,9 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt, > > > wake_up(>empty_tx_wq); > > > spin_unlock_bh(>tx_lock); > > > > > + if (htt->num_pending_tx <= 3 && !list_empty(>txqs)) > > > + ath10k_mac_tx_push_pending(ar); > > > + > > > > Just sanity checking - what's protecting htt->num_pending_tx? or is it > > serialised some other way? [...] > I can't see that any of the examples applies, but let's add READ_ONCE(), > to make sure that the compiler doesn't try to optimize this. Couldn't you just move the num_pending_tx read inside tx_lock which is 2 lines above? I think all the other manipulations are protected by tx_lock. -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH 03/14] omfs: Implement show_options
On Wed, Jul 05, 2017 at 04:24:27PM +0100, David Howells wrote: > Implement the show_options superblock op for omfs as part of a bid to get > rid of s_options and generic_show_options() to make it easier to implement > a context-based mount where the mount options can be passed individually > over a file descriptor. > > Note that the uid and gid should possibly be displayed relative to the > viewer's user namespace. > > Signed-off-by: David Howells <dhowe...@redhat.com> > cc: Bob Copeland <m...@bobcopeland.com> Acked-by: Bob Copeland <m...@bobcopeland.com> -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH 03/14] omfs: Implement show_options
On Wed, Jul 05, 2017 at 04:24:27PM +0100, David Howells wrote: > Implement the show_options superblock op for omfs as part of a bid to get > rid of s_options and generic_show_options() to make it easier to implement > a context-based mount where the mount options can be passed individually > over a file descriptor. > > Note that the uid and gid should possibly be displayed relative to the > viewer's user namespace. > > Signed-off-by: David Howells > cc: Bob Copeland Acked-by: Bob Copeland -- Bob Copeland %% https://bobcopeland.com/
Re: [PATCH 2/7] fs: support RENAME_NOREPLACE for local filesystems
On Tue, Aug 23, 2016 at 04:05:27PM +0200, Miklos Szeredi wrote:
omfs/dir.c b/fs/omfs/dir.c
> index c8cbf3b60645..417511bbe362 100644
> --- a/fs/omfs/dir.c
> +++ b/fs/omfs/dir.c
> @@ -371,12 +371,16 @@ static bool omfs_fill_chain(struct inode *dir, struct
> dir_context *ctx,
> }
>
> static int omfs_rename(struct inode *old_dir, struct dentry *old_dentry,
> - struct inode *new_dir, struct dentry *new_dentry)
> +struct inode *new_dir, struct dentry *new_dentry,
> +unsigned int flags)
> {
> struct inode *new_inode = d_inode(new_dentry);
> struct inode *old_inode = d_inode(old_dentry);
> int err;
>
> + if (flags & ~RENAME_NOREPLACE)
> + return -EINVAL;
> +
> if (new_inode) {
> /* overwriting existing file/dir */
> err = omfs_remove(new_dir, new_dentry);
> @@ -444,7 +448,7 @@ static int omfs_readdir(struct file *file, struct
> dir_context *ctx)
omfs changes look fine.
Acked-by: Bob Copeland <m...@bobcopeland.com>
--
Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 2/7] fs: support RENAME_NOREPLACE for local filesystems
On Tue, Aug 23, 2016 at 04:05:27PM +0200, Miklos Szeredi wrote:
omfs/dir.c b/fs/omfs/dir.c
> index c8cbf3b60645..417511bbe362 100644
> --- a/fs/omfs/dir.c
> +++ b/fs/omfs/dir.c
> @@ -371,12 +371,16 @@ static bool omfs_fill_chain(struct inode *dir, struct
> dir_context *ctx,
> }
>
> static int omfs_rename(struct inode *old_dir, struct dentry *old_dentry,
> - struct inode *new_dir, struct dentry *new_dentry)
> +struct inode *new_dir, struct dentry *new_dentry,
> +unsigned int flags)
> {
> struct inode *new_inode = d_inode(new_dentry);
> struct inode *old_inode = d_inode(old_dentry);
> int err;
>
> + if (flags & ~RENAME_NOREPLACE)
> + return -EINVAL;
> +
> if (new_inode) {
> /* overwriting existing file/dir */
> err = omfs_remove(new_dir, new_dentry);
> @@ -444,7 +448,7 @@ static int omfs_readdir(struct file *file, struct
> dir_context *ctx)
omfs changes look fine.
Acked-by: Bob Copeland
--
Bob Copeland %% http://bobcopeland.com/
Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
On Wed, Jul 13, 2016 at 02:45:25PM +0300, Yaniv Machani wrote:
> When a packet is received for transmission,
> a PREQ frame is sent to resolve the appropriate path to the desired
> destination.
> After path was established, any sequential PREQ will be sent only after
> dot11MeshHWMPpreqMinInterval, which usually set to few seconds.
>
> This implementation has an impact in cases where we would like to
> resolve the path quickly.
> A clear example is when a peer was disconnected from us,
> while he acted as a hop to our destination.
> Although the path table will be cleared, the next PREQ frame will be sent
> only after reaching the MinInterval.
> This will cause unwanted delay, possibly of few seconds until the traffic
> will resume.
>
> if (!(mpath->flags & MESH_PATH_RESOLVING))
> - mesh_queue_preq(mpath, PREQ_Q_F_START);
> + mesh_queue_preq(mpath, PREQ_Q_F_START, true);
What about something like this here instead:
if (!(mpath->flags & MESH_PATH_RESOLVING)) {
/* force next preq to be sent without delay */
ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
mesh_queue_preq(mpath, PREQ_Q_F_START);
}
Maybe a little more magic, but it has a comment explaining it and doesn't
add a bool parameter everywhere. Or, maybe even just do it inside
mesh_queue_preq() based on having PREQ_Q_F_START && !PREQ_Q_F_REFRESH (if
those are the only cases where "true" is passed).
Generally I try to avoid bool parameters where possible because when you
look at a callsite, you don't know immediately what "true" and "false"
mean, and also each one you add doubles the code paths through a given
function.
--
Bob Copeland %% http://bobcopeland.com/
Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving time
On Wed, Jul 13, 2016 at 02:45:25PM +0300, Yaniv Machani wrote:
> When a packet is received for transmission,
> a PREQ frame is sent to resolve the appropriate path to the desired
> destination.
> After path was established, any sequential PREQ will be sent only after
> dot11MeshHWMPpreqMinInterval, which usually set to few seconds.
>
> This implementation has an impact in cases where we would like to
> resolve the path quickly.
> A clear example is when a peer was disconnected from us,
> while he acted as a hop to our destination.
> Although the path table will be cleared, the next PREQ frame will be sent
> only after reaching the MinInterval.
> This will cause unwanted delay, possibly of few seconds until the traffic
> will resume.
>
> if (!(mpath->flags & MESH_PATH_RESOLVING))
> - mesh_queue_preq(mpath, PREQ_Q_F_START);
> + mesh_queue_preq(mpath, PREQ_Q_F_START, true);
What about something like this here instead:
if (!(mpath->flags & MESH_PATH_RESOLVING)) {
/* force next preq to be sent without delay */
ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
mesh_queue_preq(mpath, PREQ_Q_F_START);
}
Maybe a little more magic, but it has a comment explaining it and doesn't
add a bool parameter everywhere. Or, maybe even just do it inside
mesh_queue_preq() based on having PREQ_Q_F_START && !PREQ_Q_F_REFRESH (if
those are the only cases where "true" is passed).
Generally I try to avoid bool parameters where possible because when you
look at a callsite, you don't know immediately what "true" and "false"
mean, and also each one you add doubles the code paths through a given
function.
--
Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template
On Wed, Jul 13, 2016 at 02:45:40PM +0300, Yaniv Machani wrote:
> The HT capab info field inside the HT capab IE of the mesh beacon
> is incorrect (in the case of 20MHz channel width).
> To fix this driver will check configuration from cfg and
> will build it accordingly.
> +/* determine capability flags */
> + cap = sband->ht_cap.cap;
> +
> +/* if channel width is 20MHz - configure HT capab accordingly*/
> + if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
> + cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
> + cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
> + }
Is it required that HT capability match the HT operation in this case?
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 42bf0b6..5375a82 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -2349,10 +2349,7 @@ u8 *ieee80211_ie_build_ht_oper(u8 *pos, struct
> ieee80211_sta_ht_cap *ht_cap,
> ht_oper->operation_mode = cpu_to_le16(prot_mode);
> ht_oper->stbc_param = 0x;
>
> - /* It seems that Basic MCS set and Supported MCS set
> -are identical for the first 10 bytes */
> memset(_oper->basic_set, 0, 16);
> - memcpy(_oper->basic_set, _cap->mcs, 10);
This change doesn't look right (basic mcs set will be all zeroes) but
then, neither does the original code. Basic MCS set for a mesh STA should
be the mandatory MCSes according to 9.7.4.
--
Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 3/3] mac80211: mesh: fixed HT ies in beacon template
On Wed, Jul 13, 2016 at 02:45:40PM +0300, Yaniv Machani wrote:
> The HT capab info field inside the HT capab IE of the mesh beacon
> is incorrect (in the case of 20MHz channel width).
> To fix this driver will check configuration from cfg and
> will build it accordingly.
> +/* determine capability flags */
> + cap = sband->ht_cap.cap;
> +
> +/* if channel width is 20MHz - configure HT capab accordingly*/
> + if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
> + cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
> + cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
> + }
Is it required that HT capability match the HT operation in this case?
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 42bf0b6..5375a82 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -2349,10 +2349,7 @@ u8 *ieee80211_ie_build_ht_oper(u8 *pos, struct
> ieee80211_sta_ht_cap *ht_cap,
> ht_oper->operation_mode = cpu_to_le16(prot_mode);
> ht_oper->stbc_param = 0x;
>
> - /* It seems that Basic MCS set and Supported MCS set
> -are identical for the first 10 bytes */
> memset(_oper->basic_set, 0, 16);
> - memcpy(_oper->basic_set, _cap->mcs, 10);
This change doesn't look right (basic mcs set will be all zeroes) but
then, neither does the original code. Basic MCS set for a mesh STA should
be the mandatory MCSes according to 9.7.4.
--
Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped
On Wed, Jul 13, 2016 at 10:11:25AM +, Machani, Yaniv wrote: > > > Some drivers (e.g. wl18xx) expect that the last stage in the > > > de-initialization process will be stopping the beacons, similar to ap. > > > Update ieee80211_stop_mesh() flow accordingly. > > > > > How well have you tested that with other drivers? > > > > Sorry for the delayed response (I've been out) and thanks for your comments, > I have tested it with RT3572 as well, and didn't see any issue. > I'll update the comment to reflect that. I'll give this a test on ath10k and wcn36xx as they are the ones most likely to care about ordering. -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped
On Wed, Jul 13, 2016 at 10:11:25AM +, Machani, Yaniv wrote: > > > Some drivers (e.g. wl18xx) expect that the last stage in the > > > de-initialization process will be stopping the beacons, similar to ap. > > > Update ieee80211_stop_mesh() flow accordingly. > > > > > How well have you tested that with other drivers? > > > > Sorry for the delayed response (I've been out) and thanks for your comments, > I have tested it with RT3572 as well, and didn't see any issue. > I'll update the comment to reflect that. I'll give this a test on ath10k and wcn36xx as they are the ones most likely to care about ordering. -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template
On Tue, Jun 28, 2016 at 02:13:06PM +0300, Yaniv Machani wrote: > From: Meirav Kama <meir...@ti.com> > > There are several values in HT info elements of mesh beacon (built by the > mac80211) that are incorrect. Would be good to enumerate the problems here. > To fix them: > 1. mac80211 will check configuration from cfg and will build accordingly. > 2. changes made in mesh default values. What is wrong with the defaults? > sband = local->hw.wiphy->bands[band]; > if (!sband->ht_cap.ht_supported || > @@ -431,11 +433,40 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data > *sdata, > sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10) > return 0; > > +/* determine capability flags */ > + cap = sband->ht_cap.cap; There is some weird whitespace here (space instead of tabs for the comment). -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template
On Tue, Jun 28, 2016 at 02:13:06PM +0300, Yaniv Machani wrote: > From: Meirav Kama > > There are several values in HT info elements of mesh beacon (built by the > mac80211) that are incorrect. Would be good to enumerate the problems here. > To fix them: > 1. mac80211 will check configuration from cfg and will build accordingly. > 2. changes made in mesh default values. What is wrong with the defaults? > sband = local->hw.wiphy->bands[band]; > if (!sband->ht_cap.ht_supported || > @@ -431,11 +433,40 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data > *sdata, > sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10) > return 0; > > +/* determine capability flags */ > + cap = sband->ht_cap.cap; There is some weird whitespace here (space instead of tabs for the comment). -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 4/4] mac80211: sta_info: max_peers reached falsely
On Tue, Jun 28, 2016 at 02:13:07PM +0300, Yaniv Machani wrote: > From: Meirav Kama <meir...@ti.com> > > Issue happened when receiving delete_sta command without > changing plink_state from ESTAB to HOLDING before. > When receiving delete_sta command for mesh interface > verify plink_state is not ESTAB and if so, decrease > plink count and update beacon. This should be fixed already (and properly) by the patch "mac80211: Fix mesh estab links counting" -- please let us know if you have a case that's still broken with that fix. -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 4/4] mac80211: sta_info: max_peers reached falsely
On Tue, Jun 28, 2016 at 02:13:07PM +0300, Yaniv Machani wrote: > From: Meirav Kama > > Issue happened when receiving delete_sta command without > changing plink_state from ESTAB to HOLDING before. > When receiving delete_sta command for mesh interface > verify plink_state is not ESTAB and if so, decrease > plink count and update beacon. This should be fixed already (and properly) by the patch "mac80211: Fix mesh estab links counting" -- please let us know if you have a case that's still broken with that fix. -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 2/4] mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting
On Tue, Jun 28, 2016 at 02:13:05PM +0300, Yaniv Machani wrote:
> From: Maital Hahn <mait...@ti.com>
>
> Once receiving a CLOSE action frame from the disconnecting peer,
> flush all entries in the path table which has this peer as the
> next hop.
Please address the user-visible behavior in your commit messages.
Does it crash? Does it send frames to an invalid peer? Do
frames get dropped?
> In addition, upon receiving a packet, if next hop is not found,
> trigger PERQ immidiatly, instead of just putting it in the queue.
"PREQ"
Please split this into a separate patch that we can review
separately (and also give the "why" in the commit log).
> Signed-off-by: Maital Hahn <mait...@ti.com>
> Acked-by: Yaniv Machani <yani...@ti.com>
> ---
> net/mac80211/cfg.c | 1 +
> net/mac80211/mesh.c | 3 ++-
> net/mac80211/mesh_hwmp.c | 42 +-
> 3 files changed, 28 insertions(+), 18 deletions(-)
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 0c12e40..f876ef7 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1011,6 +1011,7 @@ static void sta_apply_mesh_params(struct
> ieee80211_local *local,
> if (sta->mesh->plink_state == NL80211_PLINK_ESTAB)
> changed = mesh_plink_dec_estab_count(sdata);
> sta->mesh->plink_state = params->plink_state;
> + mesh_path_flush_by_nexthop(sta);
This isn't necessary, caller should already be doing
mesh_path_flush_by_nexthop() in every case I could see. Besides it
cannot be done under plink lock.
> +++ b/net/mac80211/mesh.c
> @@ -159,7 +159,8 @@ void mesh_sta_cleanup(struct sta_info *sta)
> if (!sdata->u.mesh.user_mpm) {
> changed |= mesh_plink_deactivate(sta);
> del_timer_sync(>mesh->plink_timer);
> - }
> + } else
> + mesh_path_flush_by_nexthop(sta);
And this is already fixed in mac80211-next.
--
Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 2/4] mac80211/cfg: mesh: fix healing time when a mesh peer is disconnecting
On Tue, Jun 28, 2016 at 02:13:05PM +0300, Yaniv Machani wrote:
> From: Maital Hahn
>
> Once receiving a CLOSE action frame from the disconnecting peer,
> flush all entries in the path table which has this peer as the
> next hop.
Please address the user-visible behavior in your commit messages.
Does it crash? Does it send frames to an invalid peer? Do
frames get dropped?
> In addition, upon receiving a packet, if next hop is not found,
> trigger PERQ immidiatly, instead of just putting it in the queue.
"PREQ"
Please split this into a separate patch that we can review
separately (and also give the "why" in the commit log).
> Signed-off-by: Maital Hahn
> Acked-by: Yaniv Machani
> ---
> net/mac80211/cfg.c | 1 +
> net/mac80211/mesh.c | 3 ++-
> net/mac80211/mesh_hwmp.c | 42 +-
> 3 files changed, 28 insertions(+), 18 deletions(-)
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 0c12e40..f876ef7 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1011,6 +1011,7 @@ static void sta_apply_mesh_params(struct
> ieee80211_local *local,
> if (sta->mesh->plink_state == NL80211_PLINK_ESTAB)
> changed = mesh_plink_dec_estab_count(sdata);
> sta->mesh->plink_state = params->plink_state;
> + mesh_path_flush_by_nexthop(sta);
This isn't necessary, caller should already be doing
mesh_path_flush_by_nexthop() in every case I could see. Besides it
cannot be done under plink lock.
> +++ b/net/mac80211/mesh.c
> @@ -159,7 +159,8 @@ void mesh_sta_cleanup(struct sta_info *sta)
> if (!sdata->u.mesh.user_mpm) {
> changed |= mesh_plink_deactivate(sta);
> del_timer_sync(>mesh->plink_timer);
> - }
> + } else
> + mesh_path_flush_by_nexthop(sta);
And this is already fixed in mac80211-next.
--
Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()
On Wed, Jun 08, 2016 at 10:04:45PM -0700, Deepa Dinamani wrote: > CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will > be transitioned to use 64 bit time along with vfs in a > separate patch. > There is no plan to transistion CURRENT_TIME_SEC to use > y2038 safe time interfaces. [...] > Cc: Bob Copeland <m...@bobcopeland.com> OMFS parts look sane, thanks. -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()
On Wed, Jun 08, 2016 at 10:04:45PM -0700, Deepa Dinamani wrote: > CURRENT_TIME_SEC is not y2038 safe. current_fs_time() will > be transitioned to use 64 bit time along with vfs in a > separate patch. > There is no plan to transistion CURRENT_TIME_SEC to use > y2038 safe time interfaces. [...] > Cc: Bob Copeland OMFS parts look sane, thanks. -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH 24/31] fs/omfs: use kmemdup rather than duplicating its implementation
On Fri, Aug 07, 2015 at 09:59:30AM +0200, Andrzej Hajda wrote: > The patch was generated using fixed coccinelle semantic patch > scripts/coccinelle/api/memdup.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 > > Signed-off-by: Andrzej Hajda Thanks - Acked-by: Bob Copeland -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/31] fs/omfs: use kmemdup rather than duplicating its implementation
On Fri, Aug 07, 2015 at 09:59:30AM +0200, Andrzej Hajda wrote: The patch was generated using fixed coccinelle semantic patch scripts/coccinelle/api/memdup.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320 Signed-off-by: Andrzej Hajda a.ha...@samsung.com Thanks - Acked-by: Bob Copeland m...@bobcopeland.com -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs, omfs: add NULL terminator in the end up the token list
On Thu, Mar 12, 2015 at 04:11:09PM -0400, Sasha Levin wrote: > match_token() expects a NULL terminator at the end of the token list so that > it would know where to stop. Not having one causes it to overrun to invalid > memory. > > In practice, passing a mount option that omfs didn't recognize would sometimes > panic the system. Yikes, thanks for the catch! Acked-by: Bob Copeland > Signed-off-by: Sasha Levin -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs, omfs: add NULL terminator in the end up the token list
On Thu, Mar 12, 2015 at 04:11:09PM -0400, Sasha Levin wrote: match_token() expects a NULL terminator at the end of the token list so that it would know where to stop. Not having one causes it to overrun to invalid memory. In practice, passing a mount option that omfs didn't recognize would sometimes panic the system. Yikes, thanks for the catch! Acked-by: Bob Copeland m...@bobcopeland.com Signed-off-by: Sasha Levin sasha.le...@oracle.com -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 resend] FS/OMFS: block number sanity check during fill_super operation
On Mon, Sep 29, 2014 at 07:07:08PM +0200, Fabian Frederick wrote: > This patch defines maximum block number to 2^31. > It also converts bitmap_size and array_size to > unsigned int in omfs_get_imap > > Suggested-By: Linus Torvalds > Suggested-By: Bob Copeland > Cc: Linus Torvalds > Cc: Bob Copeland > Cc: Andrew Morton > Signed-off-by: Fabian Frederick > --- > This is untested. Acked-by: Bob Copeland I also gave it a quick test. For just plain corruption of s_num_blocks, there's a later check that one would normally hit since the number is stored in a second place, and we compare them. But if both omfs_rb->r_num_blocks and sbi->s_num_blocks are the same insane number, I agree we should give up here. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 resend] FS/OMFS: block number sanity check during fill_super operation
On Mon, Sep 29, 2014 at 07:07:08PM +0200, Fabian Frederick wrote: This patch defines maximum block number to 2^31. It also converts bitmap_size and array_size to unsigned int in omfs_get_imap Suggested-By: Linus Torvalds torva...@linux-foundation.org Suggested-By: Bob Copeland m...@bobcopeland.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Bob Copeland m...@bobcopeland.com Cc: Andrew Morton a...@linux-foundation.org Signed-off-by: Fabian Frederick f...@skynet.be --- This is untested. Acked-by: Bob Copeland m...@bobcopeland.com I also gave it a quick test. For just plain corruption of s_num_blocks, there's a later check that one would normally hit since the number is stored in a second place, and we compare them. But if both omfs_rb-r_num_blocks and sbi-s_num_blocks are the same insane number, I agree we should give up here. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] fs/omfs/inode.c: replace count*size kzalloc by kcalloc
On Wed, Jun 25, 2014 at 10:03:26PM +0200, Fabian Frederick wrote: > > > bitmap_size = DIV_ROUND_UP(sbi->s_num_blocks, 8); > > > > > Agreed - even though the FS data structures support 64-bit block > > count, I've never seen an OMFS fs with more than about 2M blocks > > (typical device had 20 gigs w/ 8k blocks). So it would make > > sense to bail in omfs_fill_super if that number is greater than > > 2^31 or so. > We could use unsigned int for bitmap instead of int or simply u64 ? It doesn't really make sense to be a signed int, sure -- but even so making it a u64 without at least including a sanity check is probably not the way to go. OMFS allocates space for the entire free-space bitmap in memory, rather than loading its blocks on demand. That's admittedly pretty dumb, but I did it so that I could eventually support those FSes without a free-space bitmap (I've never been asked for that feature, though, and didn't have ReplayTV myself, so I don't believe that actually happened). If s_num_blocks won't fit in a u32, well then that's a pretty huge chunk of memory to allocate, and would represent a disk much bigger than the ones that were available when this FS was used on a few devices. (As for why the designers used u64 for all data structures, I guess just optimism?) -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] fs/omfs/inode.c: replace count*size kzalloc by kcalloc
On Wed, Jun 25, 2014 at 08:17:17PM +0200, Fabian Frederick wrote: > kcalloc manages count*sizeof overflow. > > Cc: Bob Copeland > Cc: Andrew Morton > Signed-off-by: Fabian Frederick Acked-by: Bob Copeland -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] fs/omfs/inode.c: replace count*size kzalloc by kcalloc
On Wed, Jun 25, 2014 at 11:27:21AM -0700, Linus Torvalds wrote: > On Wed, Jun 25, 2014 at 11:17 AM, Fabian Frederick wrote: > > kcalloc manages count*sizeof overflow. > > As far as I can tell, any overflow has happened long before, in > > bitmap_size = DIV_ROUND_UP(sbi->s_num_blocks, 8); > > where 'sbi->s_num_blocks' i san u64, and 'bitmap_size' is an 'int'. > > I don't think the patch is necessarily a bad thing, but I think it > might be more important to sanity-check that part instead. Agreed - even though the FS data structures support 64-bit block count, I've never seen an OMFS fs with more than about 2M blocks (typical device had 20 gigs w/ 8k blocks). So it would make sense to bail in omfs_fill_super if that number is greater than 2^31 or so. (I am fine with the kcalloc patch too, though.) -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] fs/omfs/inode.c: replace count*size kzalloc by kcalloc
On Wed, Jun 25, 2014 at 11:27:21AM -0700, Linus Torvalds wrote: On Wed, Jun 25, 2014 at 11:17 AM, Fabian Frederick f...@skynet.be wrote: kcalloc manages count*sizeof overflow. As far as I can tell, any overflow has happened long before, in bitmap_size = DIV_ROUND_UP(sbi-s_num_blocks, 8); where 'sbi-s_num_blocks' i san u64, and 'bitmap_size' is an 'int'. I don't think the patch is necessarily a bad thing, but I think it might be more important to sanity-check that part instead. Agreed - even though the FS data structures support 64-bit block count, I've never seen an OMFS fs with more than about 2M blocks (typical device had 20 gigs w/ 8k blocks). So it would make sense to bail in omfs_fill_super if that number is greater than 2^31 or so. (I am fine with the kcalloc patch too, though.) -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] fs/omfs/inode.c: replace count*size kzalloc by kcalloc
On Wed, Jun 25, 2014 at 08:17:17PM +0200, Fabian Frederick wrote: kcalloc manages count*sizeof overflow. Cc: Bob Copeland m...@bobcopeland.com Cc: Andrew Morton a...@linux-foundation.org Signed-off-by: Fabian Frederick f...@skynet.be Acked-by: Bob Copeland m...@bobcopeland.com -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] fs/omfs/inode.c: replace count*size kzalloc by kcalloc
On Wed, Jun 25, 2014 at 10:03:26PM +0200, Fabian Frederick wrote: bitmap_size = DIV_ROUND_UP(sbi-s_num_blocks, 8); Agreed - even though the FS data structures support 64-bit block count, I've never seen an OMFS fs with more than about 2M blocks (typical device had 20 gigs w/ 8k blocks). So it would make sense to bail in omfs_fill_super if that number is greater than 2^31 or so. We could use unsigned int for bitmap instead of int or simply u64 ? It doesn't really make sense to be a signed int, sure -- but even so making it a u64 without at least including a sanity check is probably not the way to go. OMFS allocates space for the entire free-space bitmap in memory, rather than loading its blocks on demand. That's admittedly pretty dumb, but I did it so that I could eventually support those FSes without a free-space bitmap (I've never been asked for that feature, though, and didn't have ReplayTV myself, so I don't believe that actually happened). If s_num_blocks won't fit in a u32, well then that's a pretty huge chunk of memory to allocate, and would represent a disk much bigger than the ones that were available when this FS was used on a few devices. (As for why the designers used u64 for all data structures, I guess just optimism?) -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] fs/omfs/inode.c: use ULLONG_MAX instead of ~0ULL
On Sun, Jun 15, 2014 at 08:39:20AM +0200, Fabian Frederick wrote: > Use more explicit kernel.h definition > array_size = DIV_ROUND_UP(bitmap_size, sb->s_blocksize); > > - if (sbi->s_bitmap_ino == ~0ULL) > + if (sbi->s_bitmap_ino == ULLONG_MAX) > goto out; So I agree they are the same, but is there a good reason for the change? Semantically, I think of ~0ULL as "all ones" whereas ULLONG_MAX as a maximum of a magnitude comparison, which this is not really. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] fs/omfs/inode.c: use ULLONG_MAX instead of ~0ULL
On Sun, Jun 15, 2014 at 08:39:20AM +0200, Fabian Frederick wrote: Use more explicit kernel.h definition array_size = DIV_ROUND_UP(bitmap_size, sb-s_blocksize); - if (sbi-s_bitmap_ino == ~0ULL) + if (sbi-s_bitmap_ino == ULLONG_MAX) goto out; So I agree they are the same, but is there a good reason for the change? Semantically, I think of ~0ULL as all ones whereas ULLONG_MAX as a maximum of a magnitude comparison, which this is not really. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the wireless-next tree with the wireless tree
On Tue, Dec 03, 2013 at 05:09:43PM +0100, Johannes Berg wrote: > > > diff --cc net/mac80211/util.c > > > index 9f9b9bd3fd44,06265d7f8cc3.. > > > --- a/net/mac80211/util.c > > > +++ b/net/mac80211/util.c > > > @@@ -2457,9 -2481,13 +2479,8 @@@ int ieee80211_send_action_csa(struct ie > > > WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT : 0x00; > > > put_unaligned_le16(WLAN_REASON_MESH_CHAN, pos); /* Reason > > > Cd */ > > > pos += 2; > > > - pre_value = cpu_to_le16(ifmsh->pre_value); > > > - memcpy(pos, _value, 2); /* Precedence Value > > > */ > > > -if (!ifmsh->pre_value) > > > -ifmsh->pre_value = 1; > > > -else > > > -ifmsh->pre_value++; > > > + put_unaligned_le16(ifmsh->pre_value, pos);/* Precedence > > > Value */ > > > pos += 2; > > > -ifmsh->chsw_init = true; > > > } > > > > > > ieee80211_tx_skb(sdata, skb); > I think the above is correct, the pre_value assignment with 1/++ and > chsw_init moved into another function in Bob's patch. Bob? The quoted resolution looks right to me. But, I think the patch in question was actually Chun-yeow's so I'm not sure my opinion counts :) -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the wireless-next tree with the wireless tree
On Tue, Dec 03, 2013 at 05:09:43PM +0100, Johannes Berg wrote: diff --cc net/mac80211/util.c index 9f9b9bd3fd44,06265d7f8cc3.. --- a/net/mac80211/util.c +++ b/net/mac80211/util.c @@@ -2457,9 -2481,13 +2479,8 @@@ int ieee80211_send_action_csa(struct ie WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT : 0x00; put_unaligned_le16(WLAN_REASON_MESH_CHAN, pos); /* Reason Cd */ pos += 2; - pre_value = cpu_to_le16(ifmsh-pre_value); - memcpy(pos, pre_value, 2); /* Precedence Value */ -if (!ifmsh-pre_value) -ifmsh-pre_value = 1; -else -ifmsh-pre_value++; + put_unaligned_le16(ifmsh-pre_value, pos);/* Precedence Value */ pos += 2; -ifmsh-chsw_init = true; } ieee80211_tx_skb(sdata, skb); I think the above is correct, the pre_value assignment with 1/++ and chsw_init moved into another function in Bob's patch. Bob? The quoted resolution looks right to me. But, I think the patch in question was actually Chun-yeow's so I'm not sure my opinion counts :) -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: trace-cmd problem with FC19
On Thu, Oct 17, 2013 at 04:56:56PM -0400, Steven Rostedt wrote: > Hmm, are you sure? > > You may want to do both: > > sudo trace-cmd -v > which trace-cmd > > to see which version it is. To clarify - I ran into the referenced issue using an older, self-compiled version with a recent kernel. The FC19 distro version may be fine, for all I know. Arend says he used the latest version from the repo which should not be a problem, but just throwing that out there since the symptoms are similar. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: trace-cmd problem with FC19
[sorry, resent for the archives, I failed email] On Thu, Oct 17, 2013 at 4:20 PM, Steven Rostedt wrote: > On Thu, 17 Oct 2013 22:07:15 +0200 > "Arend van Spriel" wrote: > > >> > Does recording other traces work? Or is it only spicific to this module? >> >> It seems a generic issue: >> >> $ sudo trace-cmd record -e ext4:* ls >> /sys/kernel/debug/tracing/events/ext4/*/filter >> systemd-private-6pVB5Lsystemd-private-KdpFqS trace.dat.cpu0 >> trace.dat.cpu2 >> systemd-private-9hedRDtrace.dat trace.dat.cpu1 >> trace.dat.cpu3 >> trace-cmd: Interrupted system call >>recorder error in splice input >> trace-cmd: Interrupted system call >>recorder error in splice input >> trace-cmd: Interrupted system call >>recorder error in splice input Perhaps this is an instance of this bug? https://lkml.org/lkml/2013/5/31/426 tl;dr try with latest trace-cmd? I hit the above myself. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: trace-cmd problem with FC19
[sorry, resent for the archives, I failed email] On Thu, Oct 17, 2013 at 4:20 PM, Steven Rostedt rost...@goodmis.org wrote: On Thu, 17 Oct 2013 22:07:15 +0200 Arend van Spriel ar...@broadcom.com wrote: Does recording other traces work? Or is it only spicific to this module? It seems a generic issue: $ sudo trace-cmd record -e ext4:* ls /sys/kernel/debug/tracing/events/ext4/*/filter systemd-private-6pVB5Lsystemd-private-KdpFqS trace.dat.cpu0 trace.dat.cpu2 systemd-private-9hedRDtrace.dat trace.dat.cpu1 trace.dat.cpu3 trace-cmd: Interrupted system call recorder error in splice input trace-cmd: Interrupted system call recorder error in splice input trace-cmd: Interrupted system call recorder error in splice input Perhaps this is an instance of this bug? https://lkml.org/lkml/2013/5/31/426 tl;dr try with latest trace-cmd? I hit the above myself. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: trace-cmd problem with FC19
On Thu, Oct 17, 2013 at 04:56:56PM -0400, Steven Rostedt wrote: Hmm, are you sure? You may want to do both: sudo trace-cmd -v which trace-cmd to see which version it is. To clarify - I ran into the referenced issue using an older, self-compiled version with a recent kernel. The FC19 distro version may be fine, for all I know. Arend says he used the latest version from the repo which should not be a problem, but just throwing that out there since the symptoms are similar. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/21] omfs: drop vmtruncate
On Sat, Nov 03, 2012 at 10:24:58AM +0100, Marco Stornelli wrote: > Removed vmtruncate > > Signed-off-by: Marco Stornelli Thanks! Acked-by: Bob Copeland > --- > fs/omfs/file.c | 22 +++--- > 1 files changed, 15 insertions(+), 7 deletions(-) -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/21] omfs: drop vmtruncate
On Sat, Nov 03, 2012 at 10:24:58AM +0100, Marco Stornelli wrote: Removed vmtruncate Signed-off-by: Marco Stornelli marco.storne...@gmail.com Thanks! Acked-by: Bob Copeland m...@bobcopeland.com --- fs/omfs/file.c | 22 +++--- 1 files changed, 15 insertions(+), 7 deletions(-) -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] omfs: convert to use beXX_add_cpu()
On Fri, Sep 28, 2012 at 12:51:01PM +0800, Wei Yongjun wrote: > From: Wei Yongjun > > Convert cpu_to_beXX(beXX_to_cpu(E1) + E2) to use beXX_add_cpu(). > > dpatch engine is used to auto generate this patch. > (https://github.com/weiyj/dpatch) > > Signed-off-by: Wei Yongjun Thanks, Acked-by: Bob Copeland -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] omfs: convert to use beXX_add_cpu()
On Fri, Sep 28, 2012 at 12:51:01PM +0800, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Convert cpu_to_beXX(beXX_to_cpu(E1) + E2) to use beXX_add_cpu(). dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Thanks, Acked-by: Bob Copeland m...@bobcopeland.com -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/25] userns: Convert omfs to use kuid and kgid where appropriate
On Thu, Sep 20, 2012 at 06:13:52AM -0700, Eric W. Biederman wrote: > Bob Copeland writes: > > > On Thu, Sep 20, 2012 at 04:42:01AM -0700, Eric W. Biederman wrote: > >> From: "Eric W. Biederman" > >> > >> Cc: Bob Copeland > >> Acked-by: Serge Hallyn > >> Signed-off-by: Eric W. Biederman > > > > Thanks, looks good to me. > > Then I will take that as an Acked-by. ;) Sure, or here's one you can copy :) Acked-by: Bob Copeland -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/25] userns: Convert omfs to use kuid and kgid where appropriate
On Thu, Sep 20, 2012 at 04:42:01AM -0700, Eric W. Biederman wrote: > From: "Eric W. Biederman" > > Cc: Bob Copeland > Acked-by: Serge Hallyn > Signed-off-by: Eric W. Biederman Thanks, looks good to me. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/25] userns: Convert omfs to use kuid and kgid where appropriate
On Thu, Sep 20, 2012 at 04:42:01AM -0700, Eric W. Biederman wrote: From: Eric W. Biederman ebied...@xmission.com Cc: Bob Copeland m...@bobcopeland.com Acked-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Eric W. Biederman ebied...@xmission.com Thanks, looks good to me. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/25] userns: Convert omfs to use kuid and kgid where appropriate
On Thu, Sep 20, 2012 at 06:13:52AM -0700, Eric W. Biederman wrote: Bob Copeland m...@bobcopeland.com writes: On Thu, Sep 20, 2012 at 04:42:01AM -0700, Eric W. Biederman wrote: From: Eric W. Biederman ebied...@xmission.com Cc: Bob Copeland m...@bobcopeland.com Acked-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Eric W. Biederman ebied...@xmission.com Thanks, looks good to me. Then I will take that as an Acked-by. ;) Sure, or here's one you can copy :) Acked-by: Bob Copeland m...@bobcopeland.com -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT 1/1] single_chip test
> > We failed to resume after a hardware reset here for a whole second. Is > > there any > > version of ath5k which worked for you (is this a regression)? > > I cannot speak for Tino, but my ath5k never worked in MacBook -- it > failed the same way, and I believe the hardware was the same. My > understanding was that it was a known bug with PCIE devices, but I got > that out of reading list archives. Nick Kossifidis and I are in the process of debugging this -- we determined that AR5K_RESET_CTL_PCI hangs the card in hw_nic_wakeup. It doesn't look like there is any general support for 5424 cards yet. Thread is at: http://marc.info/?l=linux-wireless=120179743111458 -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ath5k failure with 2.6.24-git14
> On Tue, 5 Feb 2008 23:57:46 +0100 Tino Keitel <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and > > got the following error message from ath5k: > > > > ath5k_pci :02:00.0: registered as 'phy0' > > ath5k phy0: failed to resume the MAC Chip > > ath5k_pci: probe of :02:00.0 failed with error -5 Hi Tino, I have the same chip and it is currently unsupported by ath5k. See: http://marc.info/?l=linux-wireless=120179743111458 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ath5k failure with 2.6.24-git14
On Tue, 5 Feb 2008 23:57:46 +0100 Tino Keitel [EMAIL PROTECTED] wrote: Hi, I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and got the following error message from ath5k: ath5k_pci :02:00.0: registered as 'phy0' ath5k phy0: failed to resume the MAC Chip ath5k_pci: probe of :02:00.0 failed with error -5 Hi Tino, I have the same chip and it is currently unsupported by ath5k. See: http://marc.info/?l=linux-wirelessm=120179743111458 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT 1/1] single_chip test
We failed to resume after a hardware reset here for a whole second. Is there any version of ath5k which worked for you (is this a regression)? I cannot speak for Tino, but my ath5k never worked in MacBook -- it failed the same way, and I believe the hardware was the same. My understanding was that it was a known bug with PCIE devices, but I got that out of reading list archives. Nick Kossifidis and I are in the process of debugging this -- we determined that AR5K_RESET_CTL_PCI hangs the card in hw_nic_wakeup. It doesn't look like there is any general support for 5424 cards yet. Thread is at: http://marc.info/?l=linux-wirelessm=120179743111458 -Bob -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add_partition silently ignored errors
On 11/2/07, Dirk Hohndel <[EMAIL PROTECTED]> wrote:
> > > @@ -554,8 +573,11 @@ int rescan_partitions(struct gendisk *disk, struct
> > > block_device *bdev)
> > > if (from + size > get_capacity(disk)) {
> > > printk(" %s: p%d exceeds device capacity\n",
> > > disk->disk_name, p);
> > > + return -EBUSY;
[snip]
> I was wondering about that myself - EBUSY seemed to be used in a couple of
> other cases where there wasn't a clear match, but I think EOVERFLOW actually
> might make more sense. Opinions?
ISTR that some people wanted to keep going in this case rather than
return an error, e.g. for forensic purposes...
.. digging... here's a thread from last year:
http://lkml.org/lkml/2006/5/11/64
-Bob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add_partition silently ignored errors
On 11/2/07, Dirk Hohndel [EMAIL PROTECTED] wrote:
@@ -554,8 +573,11 @@ int rescan_partitions(struct gendisk *disk, struct
block_device *bdev)
if (from + size get_capacity(disk)) {
printk( %s: p%d exceeds device capacity\n,
disk-disk_name, p);
+ return -EBUSY;
[snip]
I was wondering about that myself - EBUSY seemed to be used in a couple of
other cases where there wasn't a clear match, but I think EOVERFLOW actually
might make more sense. Opinions?
ISTR that some people wanted to keep going in this case rather than
return an error, e.g. for forensic purposes...
.. digging... here's a thread from last year:
http://lkml.org/lkml/2006/5/11/64
-Bob
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation files in html format?
On 8/9/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > Since the network device documentation needs a rewrite, I was thinking > of using basic html format instead of just plain text. But since this would > be starting an new precedent for kernel documentation, some it seemed > like a worthwhile topic for discussion. Why not just use asciidoc? Slightly worse than plain text, slightly better than angle brackets everywhere. Nothing is more annoying than having to use lynx to read documentation because someone went tags crazy. -Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation files in html format?
On 8/9/07, Stephen Hemminger [EMAIL PROTECTED] wrote: Since the network device documentation needs a rewrite, I was thinking of using basic html format instead of just plain text. But since this would be starting an new precedent for kernel documentation, some it seemed like a worthwhile topic for discussion. Why not just use asciidoc? Slightly worse than plain text, slightly better than angle brackets everywhere. Nothing is more annoying than having to use lynx to read documentation because someone went tags crazy. -Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: If not readdir() then what?
On 4/10/07, Neil Brown <[EMAIL PROTECTED]> wrote: 2/ Some data structure using an ordered search key that is based on the filename (e.g. a B-tree with a search key that is a hash of the filename). In the first case, you just use a fixed opaque cookie for location in a directory. In the second you use the filename. If the file has been deleted, that shouldn't stop you finding the place where it would have been in the overall sort order. I can think of one (admittedly insane) FS that is between those two: 3/ an unsorted hash table, where each directory entry has an indirect pointer to its neighbor in case of hash collisions. a b -> d -> c -> e g f -> x Given 'c' as the "last" thing returned, you can hash c to find out that you are in the bucket with 'b', but if 'c' was deleted, the best you can do is return b twice or skip the chain entirely. I maintain an out-of-tree driver for such an fs (I promise I did not invent it); the best I could come up with is to encode the hash chain index in the top byte of f_pos. Needless to say, readdir is very not performant with all the seeking this hash scheme entails. -Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: If not readdir() then what?
On 4/10/07, Neil Brown [EMAIL PROTECTED] wrote: 2/ Some data structure using an ordered search key that is based on the filename (e.g. a B-tree with a search key that is a hash of the filename). In the first case, you just use a fixed opaque cookie for location in a directory. In the second you use the filename. If the file has been deleted, that shouldn't stop you finding the place where it would have been in the overall sort order. I can think of one (admittedly insane) FS that is between those two: 3/ an unsorted hash table, where each directory entry has an indirect pointer to its neighbor in case of hash collisions. a b - d - c - e g f - x Given 'c' as the last thing returned, you can hash c to find out that you are in the bucket with 'b', but if 'c' was deleted, the best you can do is return b twice or skip the chain entirely. I maintain an out-of-tree driver for such an fs (I promise I did not invent it); the best I could come up with is to encode the hash chain index in the top byte of f_pos. Needless to say, readdir is very not performant with all the seeking this hash scheme entails. -Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver
+config I2C_BLACKFIN_TWI
+ tristate "Blackfin TWI I2C support"
+ depends on I2C && (BF534 || BF536 || BF537)
+ help
+ This is the TWI I2C device driver for Blackfin 534/536/537.
+ This driver can also be built as a module. If so, the module
+ will be called i2c-bfin-twi.
Pardon my ignorance, but is there any reason to call it "Blackfin TWI"
as opposed to just "Blackfin" since TWI and I2C mean the same thing?
It lends itself to some redundancies such as:
+ pr_info("I2C: Blackfin I2C TWI driver\n");
-Bob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 4/4] Blackfin: on-chip Two Wire Interface I2C driver
+config I2C_BLACKFIN_TWI + tristate Blackfin TWI I2C support + depends on I2C (BF534 || BF536 || BF537) + help + This is the TWI I2C device driver for Blackfin 534/536/537. + This driver can also be built as a module. If so, the module + will be called i2c-bfin-twi. Pardon my ignorance, but is there any reason to call it Blackfin TWI as opposed to just Blackfin since TWI and I2C mean the same thing? It lends itself to some redundancies such as: + pr_info(I2C: Blackfin I2C TWI driver\n); -Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Apple SMC driver (hardware monitoring and control)
On Tue, Mar 20, 2007 at 03:02:14PM +0800, Nicolas Boichat wrote: > I tried neverball on my Macbook Pro 1st generation (Core Duo, not Core 2 > Duo), and the x axis in inverted, not the y axis. > > Could you confirm which axis is inverted on your Macbook? > > Also, have you tried the modified hdaps-gl, available here: > http://mactel-linux.svn.sourceforge.net/viewvc/mactel-linux/trunk/tools/hdaps-gl/ > ? Is it working correctly? Ok I tried it out again and it is in fact the x-axis that is inverted within neverball. The hdaps-gl works fine (Macbook Core Duo here). Thanks for the driver! -- Bob Copeland %% www.bobcopeland.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Apple SMC driver (hardware monitoring and control)
I tried neverball on my Macbook Pro 1st generation (Core Duo, not Core 2 Duo), and the x axis in inverted, not the y axis. Could you confirm which axis is inverted on your Macbook? Indeed, my memory is hazy and it may well have been the x-axis. I can't find my modified copy. I'll check it out again tonight along with your hdaps-gl and let you know how it goes... -Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Apple SMC driver (hardware monitoring and control)
I tried neverball on my Macbook Pro 1st generation (Core Duo, not Core 2 Duo), and the x axis in inverted, not the y axis. Could you confirm which axis is inverted on your Macbook? Indeed, my memory is hazy and it may well have been the x-axis. I can't find my modified copy. I'll check it out again tonight along with your hdaps-gl and let you know how it goes... -Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Apple SMC driver (hardware monitoring and control)
On Tue, Mar 20, 2007 at 03:02:14PM +0800, Nicolas Boichat wrote: I tried neverball on my Macbook Pro 1st generation (Core Duo, not Core 2 Duo), and the x axis in inverted, not the y axis. Could you confirm which axis is inverted on your Macbook? Also, have you tried the modified hdaps-gl, available here: http://mactel-linux.svn.sourceforge.net/viewvc/mactel-linux/trunk/tools/hdaps-gl/ ? Is it working correctly? Ok I tried it out again and it is in fact the x-axis that is inverted within neverball. The hdaps-gl works fine (Macbook Core Duo here). Thanks for the driver! -- Bob Copeland %% www.bobcopeland.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Apple SMC driver (hardware monitoring and control)
On 3/14/07, Nicolas Boichat <[EMAIL PROTECTED]> wrote: Hello, I developed, a while ago, a driver the Apple System Management Controller, which provides an accelerometer (Apple Sudden Motion Sensor), light sensors, temperature sensors, keyboard backlight control and fan control on Intel-based Apple's computers (MacBook Pro, MacBook, MacMini). Hi Nicolas, I tried out an earlier version of this patch several months ago just to play around with the joystick part of the accelerometer driver on my MacBook, and found that it was backwards in the y-direction compared to what Neverball seemed to want (of course, NB has no way to invert the joystick). I think I just did something like this in my own copy: + y = -y; input_report_abs(applesmc_idev, ABS_X, x - rest_x); input_report_abs(applesmc_idev, ABS_Y, y - rest_y); I don't claim you necessarily want to change it, but thought I'd pass it along. Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] Apple SMC driver (hardware monitoring and control)
On 3/14/07, Nicolas Boichat [EMAIL PROTECTED] wrote: Hello, I developed, a while ago, a driver the Apple System Management Controller, which provides an accelerometer (Apple Sudden Motion Sensor), light sensors, temperature sensors, keyboard backlight control and fan control on Intel-based Apple's computers (MacBook Pro, MacBook, MacMini). Hi Nicolas, I tried out an earlier version of this patch several months ago just to play around with the joystick part of the accelerometer driver on my MacBook, and found that it was backwards in the y-direction compared to what Neverball seemed to want (of course, NB has no way to invert the joystick). I think I just did something like this in my own copy: + y = -y; input_report_abs(applesmc_idev, ABS_X, x - rest_x); input_report_abs(applesmc_idev, ABS_Y, y - rest_y); I don't claim you necessarily want to change it, but thought I'd pass it along. Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] epoll use a single inode ...
+ its done only when the path is needed.). Real filesystems probably + dont want to use it, because their dentries are present in global Pedantry: it's and don't? -Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] epoll use a single inode ...
+ its done only when the path is needed.). Real filesystems probably + dont want to use it, because their dentries are present in global Pedantry: it's and don't? -Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kwatch: kernel watchpoints using CPU debug registers
On 2/7/07, Alan Stern <[EMAIL PROTECTED]> wrote: I wonder where this convention of using lower numbers to indicate higher priorities comes from... It seems to be quite prevalent even though it's obviously backwards. I agree but at least in the case of 'nice' it works in the sense that the value increases with increasing niceness. Done the other way, they would have to call it 'mean,' then someone would wonder why 'mean 10 20' prints 'No such file or directory' instead of '15'... Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kwatch: kernel watchpoints using CPU debug registers
On 2/7/07, Alan Stern [EMAIL PROTECTED] wrote: I wonder where this convention of using lower numbers to indicate higher priorities comes from... It seems to be quite prevalent even though it's obviously backwards. I agree but at least in the case of 'nice' it works in the sense that the value increases with increasing niceness. Done the other way, they would have to call it 'mean,' then someone would wonder why 'mean 10 20' prints 'No such file or directory' instead of '15'... Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
Putting the "codingstyle" control aside, often it's because things look too hackish. Also sometimes the authors know it's hackish, or just don't expect it to be generally useful to the world. I happen to own an out-of-tree filesystem which I have little desire to have reviewed for mainline: only a dozen people use it at most, and I know it would get pinged mercilessly for using buffer heads and general insanity if it ever made it past "use FUSE instead" (which would admittedly be a perfectly fine response). It works though, so I keep it up to date with the VFS changes. I do have some interest in working on various device drivers, though. Greg, assuming this somehow kicks off some avalanche of specs, will there be a ML for hooking up driver writers with specs and willing users? -- Bob Copeland %% www.bobcopeland.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
Putting the codingstyle control aside, often it's because things look too hackish. Also sometimes the authors know it's hackish, or just don't expect it to be generally useful to the world. I happen to own an out-of-tree filesystem which I have little desire to have reviewed for mainline: only a dozen people use it at most, and I know it would get pinged mercilessly for using buffer heads and general insanity if it ever made it past use FUSE instead (which would admittedly be a perfectly fine response). It works though, so I keep it up to date with the VFS changes. I do have some interest in working on various device drivers, though. Greg, assuming this somehow kicks off some avalanche of specs, will there be a ML for hooking up driver writers with specs and willing users? -- Bob Copeland %% www.bobcopeland.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: my handy-dandy, "coding style" script
On 12/19/06, Dave Jones <[EMAIL PROTECTED]> wrote: On Tue, Dec 19, 2006 at 10:46:24AM -0500, Robert P. J. Day wrote: > > just for fun, i threw the following together to peruse the tree (or > any subdirectory) and look for stuff that violates the CodingStyle > guide. clearly, it's far from complete and very ad hoc, but it's > amusing. extra searches happily accepted. I had a bunch of similar greps that I've recently been half-assedly putting together into a single script too. See http://www.codemonkey.org.uk/projects/findbugs/ I don't know if anyone cares about them anymore, since I think gcc grew some smarts in the area recently, but there are a lot of lines of code matching "static int.*= *0;" and equivalents in the driver tree. Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: my handy-dandy, coding style script
On 12/19/06, Dave Jones [EMAIL PROTECTED] wrote: On Tue, Dec 19, 2006 at 10:46:24AM -0500, Robert P. J. Day wrote: just for fun, i threw the following together to peruse the tree (or any subdirectory) and look for stuff that violates the CodingStyle guide. clearly, it's far from complete and very ad hoc, but it's amusing. extra searches happily accepted. I had a bunch of similar greps that I've recently been half-assedly putting together into a single script too. See http://www.codemonkey.org.uk/projects/findbugs/ I don't know if anyone cares about them anymore, since I think gcc grew some smarts in the area recently, but there are a lot of lines of code matching static int.*= *0; and equivalents in the driver tree. Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux slack space question
On 12/8/06, Maria Short <[EMAIL PROTECTED]> wrote: What I need is the code in the kernel that does that. I have been looking at http://lxr.linux.no/source/fs/ext3/inode.c but I could not find the specific code for partially filling the last block and placing an EOF at the end, leaving the rest to slack space. There is no place where it writes an EOF. The size of the file is stored in metadata (e.g. inode->i_size), and only the appropriate number of blocks up to i_size are read or written to. Look at ext3_get_block to see how blocks are read and allocated. Bob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux slack space question
On 12/8/06, Maria Short [EMAIL PROTECTED] wrote: What I need is the code in the kernel that does that. I have been looking at http://lxr.linux.no/source/fs/ext3/inode.c but I could not find the specific code for partially filling the last block and placing an EOF at the end, leaving the rest to slack space. There is no place where it writes an EOF. The size of the file is stored in metadata (e.g. inode-i_size), and only the appropriate number of blocks up to i_size are read or written to. Look at ext3_get_block to see how blocks are read and allocated. Bob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
