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 nee
e.kernel.org/lkml/20190703163158.937-1-huangfq.dax...@gmail.com/
--
Bob Copeland %% https://bobcopeland.com/
his issue,
> go to the 'nomem_free' label to free 'sbi->s_imap'.
Nice catch, thanks.
Acked-by: Bob Copeland
--
Bob Copeland %% https://bobcopeland.com/
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/
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!
Acke
ility, 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/
emantic 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/
emantic 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/
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 thi
> > 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/
ly
> 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..
ly
> 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/
> 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/
> 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/
e 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/
e 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/
; -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/
; -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/
test on ath10k and wcn36xx as they are the ones most
likely to care about ordering.
--
Bob Copeland %% http://bobcopeland.com/
test on ath10k and wcn36xx as they are the ones most
likely to care about ordering.
--
Bob Copeland %% http://bobcopeland.com/
sh_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 he
(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/
> 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/
ot 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/
.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/
(!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/
time interfaces.
[...]
> Cc: Bob Copeland <m...@bobcopeland.com>
OMFS parts look sane, thanks.
--
Bob Copeland %% http://bobcopeland.com/
time interfaces.
[...]
> Cc: Bob Copeland
OMFS parts look sane, thanks.
--
Bob Copeland %% http://bobcopeland.com/
s -
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/
-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
idn'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
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
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: Linu
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
han 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 m
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
4-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.
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
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
.
(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
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 l
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
; > >
> > > 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 Ch
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
ion 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
ice 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 m
? 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
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
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(-)
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
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/
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
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
> >> Ack
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
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
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
> > 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
>
> 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
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
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
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",
> > >
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,
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
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
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
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
+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
+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
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/
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
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
, 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
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
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
+ 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
+ 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
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
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
ges.
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 t
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
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
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
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
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
84 matches
Mail list logo
